Hi, Just providing some closure to this interesting edge case...
> > Thank you for this detailed report, this is *very* useful. As you tracked > the crash to happen inside openssl, I think you should file a report to > centos/redhat because it's a security issue. 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. > 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... > 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. > 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. > 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 Cheers, James
