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