oss-sec mailing list archives
Re: CVE-2013-1900 looks like an OpenSSL bug
From: Florian Weimer <fw () deneb enyo de>
Date: Fri, 12 Apr 2013 22:02:07 +0200
* Solar Designer:
On Fri, Apr 12, 2013 at 09:14:46PM +0200, Florian Weimer wrote:I believe it is wrong to fix this in PostgreSQL. Rather, this is a bug in the OpenSSL fork protection code.Yes, I suggested this as a possibility here: http://www.openwall.com/lists/oss-security/2013/04/04/2
Oops, I missed that one.
It should either install a fork hook,What is a fork hook, and how would it install one?
See pthread_atfork(). On Linux, it's not part of libc proper, so you'd have to link against libpthread (which OpenSSL currently does anyway, unnecessarily, and has performance drawbacks on Linux).
or reseed the PRNG from /dev/urandom if a PID change is detected.Yes, or the PID may simply be mixed in on each and every request for a pseudo-random number. (Isn't this already the case? Need to check.)
That's what's done, but it doesn't help if the seed *and* the PID are reused, which is what was noticed in the PostgreSQL context (if I understood the commit message correctly). Mixing the PID is just not good enough, you need call getpid(), compare the result to the previously seen PID, and reseed if there's a change. Gutmann's thesis disagrees with that, claiming (without proof) that, "The only way to reliably solve this problem is to borrow a technique from the field of transaction processing and use a two-phase commit (2PC) to extract data from the pool." But I think this requirement mainly stems from a desire to avoid reseeding at all cost. He doesn't discuss the issue of PID-and-seed reuse, as far as I can tell.
Current thread:
- CVE-2013-1900 looks like an OpenSSL bug Florian Weimer (Apr 12)
- Re: CVE-2013-1900 looks like an OpenSSL bug Solar Designer (Apr 12)
- Re: CVE-2013-1900 looks like an OpenSSL bug Florian Weimer (Apr 12)
- Re: CVE-2013-1900 looks like an OpenSSL bug Solar Designer (Apr 12)