diff --git a/templates/index.html b/templates/index.html index 31944360..c380b666 100644 --- a/templates/index.html +++ b/templates/index.html @@ -9,26 +9,21 @@

- Upcoming security releases + Important security updates released!

-

3rd April 2013

+

4th April 2013

-The PostgreSQL Global Development Group will be releasing a security update -for all supported versions tomorrow, Thursday April 4th, 2013. This release -will include a fix for a high-exposure security vulnerability. All users are -strongly urged to apply the update as soon as it is available. -

-

-We are providing this advance notice so that users may schedule an update of -their production systems on or shortly after April 4th. -

-

-As always, update releases only require installation of packages and a -database system restart. You do not need to dump/restore or use pg_upgrade -for this update release. + The PostgreSQL Global Development Group announces updates for all active + branches of PostgreSQL, specifically versions 9.2.4, 9.1.9, 9.0.13 and 8.4.17. + These releases fix a number of bugs in previous releases, including + a serious security issue.

+

Users are strongly advised to upgrade as soon as possible.

diff --git a/templates/pages/support/security.html b/templates/pages/support/security.html index 95a5af2d..f8340f48 100644 --- a/templates/pages/support/security.html +++ b/templates/pages/support/security.html @@ -61,6 +61,51 @@ to determine if the bug affects specific installations or not. Description + + CVE-2013-1899 + 9.2, 9.1, 9.0 + 9.2.4, 9.1.9, 9.0.13 + core server + A + A connection request containing a database name that begins with "-" may be crafted to damage or destroy files within a server's data directory + + + + CVE-2013-1900 + 9.2, 9.1, 9.0, 8.4 + 9.2.4, 9.1.9, 9.0.13, 8.4.17 + contrib module + C + Random numbers generated by contrib/pgcrypto functions may be easy for another database user to guess + + + + CVE-2013-1901 + 9.2, 9.1 + 9.2.4, 9.1.9 + core server + D + An unprivileged user can run commands that could interfere with in-progress backups. + + + + CVE-2013-1902 + 9.2, 9.1, 9.0, 8.4, 8.3 + 9.2.4-1, 9.1.9-1, 9.0.13-1, 8.4.17-1, 8.3.23-3 + packaging + C + EnterpriseDB's installers for Linux and Mac OS X created a directory and file in /tmp with predictable names. + + + + CVE-2013-1903 + 9.2, 9.1, 9.0, 8.4, 8.3 + 9.2.4-1, 9.1.9-1, 9.0.13-1, 8.4.17-1, 8.3.23-3 + packaging + C + EnterpriseDB's installers for Linux and Mac OS X passed the database superuser password to a script in an insecure fashion. + + CVE-2013-0255 9.2, 9.1, 9.0, 8.4, 8.3 @@ -569,11 +614,16 @@ The following component references are used in the above table: - + client contrib module This vulnerability exists in a contrib module used on the client only. + + packaging + This vulnerability exists in PostgreSQL binary packaging, e.g. an installer or RPM. + + diff --git a/templates/pages/support/security/faq/2013-04-04.html b/templates/pages/support/security/faq/2013-04-04.html new file mode 100644 index 00000000..7e6c0b90 --- /dev/null +++ b/templates/pages/support/security/faq/2013-04-04.html @@ -0,0 +1,183 @@ +{%extends "base/page.html"%} +{%block title%}2013-04-04 Security Release FAQ{%endblock%} +{%block contents%} + +

2013-04-04 Security Release FAQ

+ +

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.

+ +

Are there any known exploits "in the wild" for this vulnerability?

+

There are no known exploits at the time of release.

+ +

Who is particularly vulnerable because of this issue?

+

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.

+ +

What is the nature of the vulnerability?

+

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.

+ +

What potential exploits are enabled by this vulnerability?

+
    +
  1. Persistent Denial of Service: an unauthenticated attacker may use this + vulnerability to cause PostgreSQL error messages to be appended to targeted + files in the PostgreSQL data directory on the server. Files corrupted in + this way may cause the database server to crash, and to refuse to restart. + The database server can be fixed either by editing the files and removing + the garbage text, or restoring from backup.
    2. +
  2. Configuration Setting Privilege Escalation: in the event that an attacker + has a legitimate login on the database server, and the server is configured + such that this user name and the database name are identical (e.g. user + web, database web), then this vulnerability may be used to + temporarily set one configuration variable with the privileges of the + superuser.
    3. +
  3. Arbitrary Code Execution: if the attacker meets all of the qualifications + under 2 above, and has the ability to save files to the filesystem as well + (even to the tmp directory), then they can use the vulnerability to + load and execute arbitrary C code. SELinux will prevent this specific + type of exploit.
    4. +
+ +

Which major versions of PostgreSQL are affected?

+

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.

+ +

How can users protect themselves?

+ +

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.

+ +

Who was given access to the information about the vulnerability?

+

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

+ +

When was the vulnerability discovered?

+

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.

+ +

Who discovered the vulnerability?

+

Mitsumasa Kondo and Kyotaro Horiguchi of NTT Open Source Software Center +while conducting a security audit. NTT is a longtime contributor to PostgreSQL. +

+ +

How was the vulnerability reported?

+

Kondo-san and Horiguchi-san sent email to security@postgresql.org.

+ +

As reported by TechCrunch and Hacker News, some entities including cloud +platform provider Heroku were given early access. Why did this occur?

+

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 both to secure their +infrastructure and to use their deployment as a test-bed for the security +patches, in order 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.

+ +

Who was given access to the code before the official release?

+

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.

+ +

How can end-users with large deployments or security-sensitive applications +obtain early access security information?

+

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.

+ +

Was taking the repository private while this security discussion was ongoing + the proper thing to do?

+

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, pgsql-hackers@postgresql.org, 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 +pgsql-announce@postgresql.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.

+ +

How is the PostgreSQL project organized?

+

PostgreSQL Global Development Group (PGDG) is a volunteer-run, global +organization. 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.

+ +

How are new members added to the Security Team or Packagers?

+

Membership in both groups is maintained by the Core Team.

+ +

How often does PostgreSQL find new security vulnerabilities?

+

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.

+ +

How was the vulnerability introduced?

+

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.

+ +

Who discovers vulnerabilities in PostgreSQL?

+

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:

+ + +

What else is included in this release?

+

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.

+ +{%endblock%} +