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