Hi James, On Thu, Feb 06, 2014 at 08:36:00PM +0000, James Hogarth wrote: > CentOS is bug-for-bug compatible (see recent libsvr2 issue there) and > seeing as we don't at this time have a support contract with RH plus it it > is not reproducible on the current release (the glibc in 6.5 fixes it) I > doubt there will be any traction in that direction.
Possible, but according to this below, 6.4 is very recent and supposed to be maintained till 2015 : https://access.redhat.com/site/support/policy/updates/errata/ So maybe they're interested in backporting the fix from 6.5 into 6.4. There are some Red Hat people here on the list, maybe they could relay that information internally (Ryan ?). > > It's possible that the bug > > is easier to trigger with haproxy or with a specific version of it than > > other products, but nevertheless, no lib should ever crash depending on > > the traffic so I suspect there's an unchecked error code in it causing a > > NULL pointer to be dereferenced. > > > > > It wasn't a null pointer but an explicit choice of behaviour in libkrb5 it > seems... Indeed, but given the code you showed, I suspect that the abort() was put there a bit in a hurry or as a sign of despair. abort() followed by return -1 is pointless and not that common! > > In 1.5-dev12, I believe we did not yet support SNI, which could be an > > explanation for the different behaviour between the two versions. I > > think that the chroot is needed to trigger the bug simply because the > > glibc does not find a file it looks up, and causes a different return > > code to be fed to openssl. > > > This is possible and seems a likely possibility ... Incidentally blocking > one of the 'ciphers of death' by not permitting it on the bind also appears > to avoid the code path - the 'cipher not permitted' gets triggered before > whatever leads to the query through libkrb that results in the SIGABRT. Yes so it seems you needed a perfect alignment of planets for this to happen, but that in your environments, planets are always aligned :-/ > > It would be useful to know if you can also > > trigger the issue using the legacy openssl library instead of the > > distro's version (just pick 1.0.0l or 1.0.1f from the site if you're > > willing to rebuild it). > > > > > We probably won't get a chance to do this and we're unlikely to move off of > the libssl supported by the distro due to the added maintenance overhead. I easily understand! Especially since you really want to rely on someone who knows it well to correctly backport only the right fixes and not the bogus ones from upstream... > > Thanks a lot! > > Willy > > > > > Not a problem ... our Head of IS did a detailed write up on our > investigation process and findings at his blog if you are interested: > > http://blog.tinola.com/?e=36 Ah cool, thanks for the link! Cheers, Willy
