PostgreSQL security update coming April 4

- 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
http://git.postgresql.org/pg/commitdiff/0d1ecd6300191a450...