PostgreSQL security update coming April 4

[Posted March 29, 2013 by corbet]

From:		Selena Deckelmann <selena-AT-postgresql.org>
To:		pgsql-announce-AT-postgresql.org
Subject:		[ANNOUNCE] Upcoming PostgreSQL Security Release: April 4, 2013
Date:		Thu, 28 Mar 2013 16:13:44 -0700
Message-ID:		<CAN1EF+x0dmwMFuJGWuXMiRQtyT1s=Pe95f9gaF=uVCEa=V61fQ@mail.gmail.com>
Archive‑link:		Article

The PostgreSQL Project will be releasing a security update for all
supported versions on Thursday April 4th, 2013. This release will include a
fix for a high-exposure security vulnerability. All users are strongly
urged to apply the update as soon as it is available.

We are providing this advance notice so that users may schedule an update
of their production systems on or shortly after April 4th.

As always, update releases only require installation of packages and a
database system restart. You do not need to dump/restore or use pg_upgrade
for this update release.

PostgreSQL security update coming April 4

Posted Mar 31, 2013 1:32 UTC (Sun) by cesarb (subscriber, #6266) [Link] (1 responses)

Found a blog post with more information: http://blog.hagander.net/archives/212-About-security-upda...

PostgreSQL security update coming April 4

Posted Apr 4, 2013 13:44 UTC (Thu) by idupree (guest, #71169) [Link]

It's now released: http://www.postgresql.org/about/news/1456/

PostgreSQL security update coming April 4

Posted Apr 4, 2013 8:43 UTC (Thu) by Comet (subscriber, #11646) [Link]

PostgreSQL Weekly News for March 31st had this item; so whatever the Bad issue is, it's worse than this:

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