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".
hourly2PostgreSQL security update coming April 4
http://lwn.net/Articles/545905/rss
2013-04-04T13:44:53+00:00idupree
<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:00Comet
<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:00cesarb
<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>