Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 4 Apr 2013 18:39:31 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: PostgreSQL security update

Hi,

A heads-up in case someone missed today's news:

http://www.postgresql.org/about/news/1456/
http://www.postgresql.org/support/security/faq/2013-04-04/

Prior (non-)announcement:

http://www.postgresql.org/message-id/14040.1364490185@sss.pgh.pa.us

"8.3 has reached EOL in February 2013 [...] there will be no fix for 8.3":

http://www.postgresql.org/message-id/CABUevEyk=_fZG7yQrFz4n18AQRdFbvYE=V2X=sYihUf=cGVnWA@mail.gmail.com

http://www.postgresql.org/support/security/ lists pre-9.0 versions as
only vulnerable to a subset of the issues, though.  I hope this does in
fact imply that older versions are not vulnerable to the rest of the
issues.

More detail on the randomness leak:

http://www.postgresql.org/message-id/E1UKzBn-0006c2-Cy@gemulon.postgresql.org
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=21ce40c8eab4d0da110fb6e05e9d9ec20d73d8b3

This is a bit puzzling.  What follows is my own thinking on the matter,
somewhat out of context (as I did not discuss this issue with PostgreSQL
folks at all, and I did not specifically review the code):

If OpenSSL's CSPRNG constantly mixes in the PID and does so correctly,
then its output stream after fork() should change in a such a way that
the stream of another sibling process is not predictable, despite of the
low entropy of the PID.  However, there's a major exception to this: an
attacker who can read the process' memory can recover the internal
state, which does allow to predict a sibling process' random numbers.

If the above is correct, then at least one of the following must be true:

1. PostgreSQL developers assume that memory of a postmaster child
process may be read by an attacker.  Sub-options:

1.1. Such capability might be there on purpose (does some feature of
PostgreSQL deliberately expose it?)

1.2. PostgreSQL developers may be making this assumption because the
existence of bugs of this sort is almost certain in practice, or/and
just to be on the safe side.

2. There's an issue (or at least a lack of a security feature) in
OpenSSL's CSPRNG, where the PID mixing is not good enough even in
absence of memory read features or bugs.  If so, shouldn't we look into
this closely and consider fixing it in OpenSSL?  Does the code possibly
avoid obtaining the PID too often for better performance?  If so, that
may be reasonable, but this (and the impact and the mitigation) need to
be clearly documented (for OpenSSL).

Also, as far as we may be concerned about fork()'ed process memory
reads, does RAND_cleanup() (try to) securely wipe the old randomness
state, including what may be left on stack and in CPU registers? ;-)

3. PostgreSQL developers are confused, and are over-estimating the risk.
(This is unlikely.)

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.