Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130412194330.GA12353@openwall.com>
Date: Fri, 12 Apr 2013 23:43:30 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: CVE-2013-1900 looks like an OpenSSL bug

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

> It should either install a fork hook,

What is a fork hook, and how would it install one?

> 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.)
If such mixing, including of that of the rest of the entropy sources,
is cryptographically strong, then one sibling process' pseudo-random
number stream would not reveal another sibling's, unless there's also a
memory contents leak.  The fact that the PID itself is low-entropy is OK
as long as sufficient entropy is obtained from other sources (before the
fork() is OK) and its mixing is cryptographically strong (and was such
on any pre-fork() requests for random numbers as well), again assuming
no memory contents leak from any of the processes.

Alexander

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.