The following versions make up this release:
While this FAQ covers the 2013-04-04 PostgreSQL Security Update in general, most of its contents focus on the primary security vulnerability patched in the release, CVE-2013-1899.
There were no known exploits at the time of release.
Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable. Users whose servers are only accessible on protected internal networks, or who have effective firewalling or other network access restrictions, are less vulnerable.
This is a good general rule for database security: do not allow port access to the database server from untrusted networks unless it is absolutely necessary. This is as true, or more true, of other database systems as it is of PostgreSQL.
The vulnerability allows users to use a command-line switch for a PostgreSQL connection intended for single-user recovery mode while PostgreSQL is running in normal, multiuser mode. This can be used to harm the server.
Versions 9.0, 9.1 and 9.2.
Users of version 8.4 are not affected. Users of version 8.3 and earlier are not affected by this issue, but are vulnerable to other unpatched security vulnerabilities, since those versions are EOL.
Use of advanced security frameworks, such as SELinux with PostgreSQL's SEPostgres extension, also lessen or eliminate the exposure and potential damage from PostgreSQL security vulnerabilities.
Specifics about the vulnerability were first disclosed to our security team.
The PostgreSQL Global Development Group (PGDG) has had, for several years, a policy granting engineers who build PostgreSQL binary packages to be distributed to the public (such as RPMs and Windows installers) early access to be able to release information and code so that packages can be ready on the official release date. This applied to both minor and major releases. Given the increasing prevalence of PostgreSQL-as-a-Service (PGaaS) as a distribution mechanism, we are revising this policy to accomodate the case of the cloud providers. The new policy is still being edited and should be available soon.
This vulnerability was first reported to the PostgreSQL Global Development Group (PGDG) security team on March 12, 2013.
We filed for the CVE, with the assistance of the Red Hat security team, on March 27.
Mitsumasa Kondo and Kyotaro Horiguchi of NTT Open Source Software Center while conducting a security audit. NTT is a longtime contributor to PostgreSQL.
Kondo-san and Horiguchi-san sent email to firstname.lastname@example.org.
Heroku was given access to updated source code which patched the vulnerability at the same time as other packagers. Because Heroku was especially vulnerable, the PostgreSQL Core Team worked with them -- to secure their infrastructure and to use their deployment as a test-bed for the security patches. This helped to verify that the security update did not break any application functionality. Heroku has a history both of working closely with community developers, and of testing experimental features in their PostgreSQL service.
We have two teams that communicate on private lists hosted on the PGDG infrastructure. Both teams had access to the source code prior to the release of any packages for analyzing the security patch and then creating packages for distributing PostgreSQL binaries. These are our Security Team and our Packagers List. In both cases, these groups had early access in order to participate in patching the security hole.
At this time, the PostgreSQL project does not provide users who are not directly involved in patching security vulnerabilities or packaging PostgreSQL for other users early access to security information, patches, or code. It is possible that at some time in the future we may be in a position to offer such access, but we are not able to now.
Given the severity of the vulnerability, the PostgreSQL Core team deliberated and determined the security risk posed by having the source code for the fix available before the packages were made available outweighed the public’s interest in having immediate access.
Normal procedure for sharing information about security releases is to send an announcement our developer mailing list, email@example.com, a week before a new release. Tom Lane did this. Then, due to the severity of the security vulnerability, we also sent an announcement to firstname.lastname@example.org and to our RSS News feed on our website homepage. We did this because we wanted to give DBAs sufficient time to plan for a maintenance window to upgrade.
The timing of the announcements and the release was based on the availability of volunteer packagers and release managers to conduct the release.
PostgreSQL Global Development Group (PGDG) is a volunteer-run, global organisation. We have a six-person core team, a number of Major Contributors and several mailing lists that make up the centralized portion of our community. See here for details about contributors.
Membership in both groups is maintained by the Core Team.
We find zero to seven minor security issues a year. This is the first security issue of this magnitude since 2006: the "backslash escape encoding issue", which affected MySQL and a few other database systems as well.
It was created as a side effect of a refactoring effort to make establishing new connections to a PostgreSQL server faster, and the associated code more maintainable.
We are fortunate to have a large pool of security engineers who test PostgreSQL regularly and responsibly report security issues so that they can be fixed. This includes:
This release also updates four other, minor, security issues which are detailed on the security page and in the release announcement. It includes a number of bug fixes for PostgreSQL as well, most notably fixes for two potential data corruption issues with binary replication.