Date: Fri, 12 Apr 2013 22:02:07 +0200 From: Florian Weimer <fw@...eb.enyo.de> To: oss-security@...ts.openwall.com Subject: Re: CVE-2013-1900 looks like an OpenSSL bug * 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.
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.