LWN: Comments on "PostgreSQL security update coming April 4" http://lwn.net/Articles/545172/ This is a special feed containing comments posted to the individual LWN article titled "PostgreSQL security update coming April 4". hourly 2 PostgreSQL security update coming April 4 http://lwn.net/Articles/545905/rss 2013-04-04T13:44:53+00:00 idupree <div class="FormattedComment"> It's now released: <a href="http://www.postgresql.org/about/news/1456/">http://www.postgresql.org/about/news/1456/</a><br> </div> PostgreSQL security update coming April 4 http://lwn.net/Articles/545879/rss 2013-04-04T08:43:37+00:00 Comet <div class="FormattedComment"> PostgreSQL Weekly News for March 31st had this item; so whatever the Bad issue is, it's worse than this:<br> <p> - Reset OpenSSL randomness state in each postmaster child process.<br> Previously, if the postmaster initialized OpenSSL's PRNG (which it<br> will do when ssl=on in postgresql.conf), the same pseudo-random<br> state would be inherited by each forked child process. The problem<br> is masked to a considerable extent if the incoming connection uses<br> SSL encryption, but when it does not, identical pseudo-random state<br> is made available to functions like contrib/pgcrypto. The process's<br> PID does get mixed into any requested random output, but on most<br> systems that still only results in 32K or so distinct random<br> sequences available across all Postgres sessions. This might allow<br> an attacker who has database access to guess the results of "secure"<br> operations happening in another session. To fix, forcibly reset the<br> PRNG after fork(). Each child process that has need for random<br> numbers from OpenSSL's generator will thereby be forced to go<br> through OpenSSL's normal initialization sequence, which should<br> provide much greater variability of the sequences. There are other<br> ways we might do this that would be slightly cheaper, but this<br> approach seems the most future-proof against SSL-related code<br> changes. This has been assigned CVE-2013-1900, but since the issue<br> and the patch have already been publicized on pgsql-hackers, there's<br> no point in trying to hide this commit. Back-patch to all supported<br> branches. Marko Kreen<br> <a href="http://git.postgresql.org/pg/commitdiff/0d1ecd6300191a450978ca2fcd12bbbb7c5e65e6">http://git.postgresql.org/pg/commitdiff/0d1ecd6300191a450...</a><br> <p> </div> PostgreSQL security update coming April 4 http://lwn.net/Articles/545345/rss 2013-03-31T01:32:11+00:00 cesarb <div class="FormattedComment"> Found a blog post with more information: <a href="http://blog.hagander.net/archives/212-About-security-updates-and-repository-lockdown.html">http://blog.hagander.net/archives/212-About-security-upda...</a><br> </div>