oss-security - CVE-2013-1900 looks like an OpenSSL bug

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Fri, 12 Apr 2013 21:14:46 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: oss-security@...ts.openwall.com
Subject: CVE-2013-1900 looks like an OpenSSL bug

I was made aware of this commit to the PostgreSQL sources:

commit 0d1ecd6300191a450978ca2fcd12bbbb7c5e65e6
Author: Tom Lane <tgl@....pgh.pa.us>
Date:   Wed Mar 27 18:50:21 2013 -0400

    Reset OpenSSL randomness state in each postmaster child process.
    
    Previously, if the postmaster initialized OpenSSL's PRNG (which it will do
    when ssl=on in postgresql.conf), the same pseudo-random state would be
    inherited by each forked child process.  The problem is masked to a
    considerable extent if the incoming connection uses SSL encryption, but
    when it does not, identical pseudo-random state is made available to
    functions like contrib/pgcrypto.  The process's PID does get mixed into any
    requested random output, but on most systems that still only results in 32K
    or so distinct random sequences available across all Postgres sessions.
    This might allow an attacker who has database access to guess the results
    of "secure" operations happening in another session.
    
    To fix, forcibly reset the PRNG after fork().  Each child process that has
    need for random numbers from OpenSSL's generator will thereby be forced to
    go through OpenSSL's normal initialization sequence, which should provide
    much greater variability of the sequences.  There are other ways we might
    do this that would be slightly cheaper, but this approach seems the most
    future-proof against SSL-related code changes.
    
    This has been assigned CVE-2013-1900, but since the issue and the patch
    have already been publicized on pgsql-hackers, there's no point in trying
    to hide this commit.
    
    Back-patch to all supported branches.
    
    Marko Kreen

I believe it is wrong to fix this in PostgreSQL.  Rather, this is a
bug in the OpenSSL fork protection code.  It should either install a
fork hook, or reseed the PRNG from /dev/urandom if a PID change is
detected.

Comments?

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.