November 21, 2024: PostgreSQL 17.2, 16.6, 15.10, 14.15, 13.18, and 12.22 Released!

PostgreSQL 2010-10-05 Security Update

Posted on 2010-10-05

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:

If you'd like a more detailed explanation of the vulnerability, an FAQ is available.

This post has been migrated from a previous version of the PostgreSQL website. We apologise for any formatting issues caused by the migration.