Re: CVE-2013-1900 looks like an OpenSSL bug

[Florian Weimer <fw () deneb enyo de>]

* 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.