November 14, 2024: PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 Released!

Security Update 2012-02-27 released

Posted on 2012-02-27 by PostgreSQL Global Development Group

The PostgreSQL Global Development Group today released security updates for all active branches of the PostgreSQL object-relational database system, including versions 9.1.3, 9.0.7, 8.4.11 and 8.3.18.

Users of pg_dump, users of SSL certificates for validation or users of triggers using SECURITY DEFINER should upgrade their installations immediately. All other database administrators are urged to upgrade your version of PostgreSQL at the next scheduled downtime. More details on the security fixes are included below.

Features affected by bug fixes in this update include: binary replication and hot standby, GIN, WITH, foreign data wrappers, PL/pgsql, PL/python, inet datatype, intarray, pgcrypto, pg_upgrade, pg_restore and pg_dump. Users of these features should apply the updates as soon as possible.

This release contains 45 fixes to version 9.1, and a smaller number of fixes to older versions, including:

  • Fix btree index corruption from insertions concurrent with vacuuming
  • Recover from errors occurring during WAL replay of DROP TABLESPACE
  • Fix transient zeroing of shared buffers during WAL replay
  • Fix postmaster to attempt restart after a hot-standby crash
  • Fix corner case in SSI transaction cleanup
  • Update per-column permissions, not only per-table permissions, when changing table owner
  • Fix handling of data-modifying WITH subplans in READ COMMITTED rechecking
  • Fix for "could not find plan for CTE" failures
  • Fix unsupported node type error caused by COLLATE in an INSERT expression
  • Avoid crashing when we have problems deleting table files post-commit
  • Fix recently-introduced memory leak in processing of inet/cidr
  • Fix GIN cost estimation to handle column IN (...) index conditions
  • Fix I/O-conversion-related memory leaks in plpgsql
  • Teach pg_upgrade to handle renaming of plpython's shared library (affecting upgrades to 9.1)

As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Perform post-update steps after the database is restarted.

This update includes three security fixes for the following issues:

  • CVE-2012-0866: Permissions on a function called by a trigger are not checked.

This fix prevents users from defining triggers which execute functions on which the user does not have EXECUTE permission.

CREATE TRIGGER failed to make any permissions check on the trigger function to be called. An unprivileged database user could attach a trigger function to a table they owned and cause it to be called on data of their choosing. Normally, this would execute with the permissions of a table owner, and thus not give additional capability. However, if a trigger function is marked SECURITY DEFINER, privilege escalation is possible.

  • CVE-2012-0867: SSL certificate name checks are truncated to 32 characters, allowing connection spoofing under some circumstances.

This fixes SSL common name truncation, which could allow hijacking of an SSL connection under exceptional circumstances.

When using SSL certificates, both clients and servers can be configured to verify the other's host name against the common name in the certificate it presents. However, the name extracted from the certificate was incorrectly truncated to 32 characters. Normally that just results in a verification failure, but if the actual host name of a machine is exactly 32 characters long, it could, in principle, be spoofed. The risk of this actually happening appears unlikely, and an attacker would still need to take additional steps outside of PostgreSQL to succeed with an exploit.

  • CVE-2012-0868: Line breaks in object names can be exploited to execute code when loading a pg_dump file.

This fix removes '\n' and '\r' from dumpfile comments.

pg_dump copied object names into comments in a SQL script without sanitizing them. An object name that includes a newline followed by an SQL command would result in a dump script in which the SQL command is exposed for execution. When and if the dump script is reloaded, the command would be executed with the privileges of whoever is running the script - often a superuser.

All supported versions of PostgreSQL are affected. See the release notes for each version for a full list of changes with details of the fixes and steps.

Download new versions now: