The PostgreSQL Global Development Group today released security
updates for all active branches of the PostgreSQL object-relational
database system, including versions 9.0.1, 8.4.5, 8.3.12, 8.2.18,
8.1.22, 8.0.26 and 7.4.30. This is the final update for PostgreSQL
versions 7.4 and 8.0.
This update contains a security patch that prevents unauthorized
privilege escalation by modifying "trusted" procedural language
functions, as well as multiple fixes for minor uptime, data integrity
and error handling issues.
Users of PL/perl and PL/tcl procedural languages and SECURITY DEFINER
should update their installations immediately. All other database
administrators are urged to update your version of PostgreSQL at the
next scheduled downtime.
Minor releases 7.4.30 and 8.0.26 are the final releases for PostgreSQL
7.4 and 8.0 as both versions are no longer supported. The PostgreSQL
community will also stop releasing updates for version 8.1 later this
year. Users are encouraged to upgrade to a newer version as soon as
possible. See our release support policy:
http://wiki.postgresql.org/wiki/PostgreSQL_Release_Support_Policy
The security vulnerability allows any ordinary SQL users with
"trusted" procedural language usage rights to modify the contents of
procedural language functions at runtime. As detailed in
CVE-2010-3433, an authenticated user can accomplish privilege
escalation by hijacking a SECURITY DEFINER function (or some other
existing authentication-change operation). The mere presence of the
procedural languages does not make your database application
vulnerable.
PL/Perl and PL/tcl are patched in this release; a patch for PL/PHP is
pending. All 3rd party procedural languages with a trusted version are
also vulnerable to the issue. Advisory CVE-2010-3433:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3433
This release includes numerous internal documentation updates and 130
bugfixes, including:
* Prevent show_session_authorization() from crashing within autovacuum
processes, backpatched to all supported versions;
* Fix connection leak after duplicate connection name errors, fix
handling of connection names longer than 62 bytes and improve
contrib/dblink's handling of tables containing dropped columns,
backpatched to all supported versions;
* Defend against functions returning setof record where not all the
returned rows are actually of the same rowtype, backpatched to 8.0;
* Fix possible duplicate scans of UNION ALL member relations,
backpatched to 8.2;
* Reduce PANIC to ERROR on infrequent btree failure cases, backpatched
to 8.2;
* Add hstore(text, text) function to contrib/hstore, to support
migration away from the => operator, which was deprecated in 9.0.
Function support backpatched to 8.2;
* Treat exit code 128 as non-fatal on Win32, backpatched to 8.2;
* Fix failure to mark cached plans as transient, causing CREATE INDEX
CONCURRENTLY to not be used right away, backpatched to 8.3;
* Fix evaluation of inner side of an outer join is a sub-select with
non-strict expressions in its output list, backpatched to 8.4;
* Allow full SSL certificate verification to succeed in the case where
both host and hostaddr are specified, backpatched to 8.4;
* Improve parallel restore's ability to cope with selective restore
(-L option), backpatched to 8.4 with caveats;
* Fix failure of "ALTER TABLE t ADD COLUMN c serial" when done by
non-owner, 9.0 only.
* Several bugfixes for join removal, 9.0 only.
See the release notes for a full list of changes with details.
As with other minor releases, users are not required to dump and
reload their database in order to apply this update release; you may
simply shut down PostgreSQL and update its binaries. Users skipping
more than one update may need to check the release notes for extra,
post-update steps.
Download new versions now:
* Main download page: http://www.postgresql.org/download
* Source code: http://www.postgresql.org/ftp/source/
* Binary packages: http://www.postgresql.org/ftp/binary/
* One-click installer, including Windows packages:
http://www.enterprisedb.com/products/pgdownload.do
If you'd like a more detailed explanation of the vulnerability, a FAQ
is available: http://wiki.postgresql.org/wiki/20101005securityrelease