20140220securityrelease

2014-02-20 Consolidated Security Update

The 2014-02-20 update contains fixes for multiple security issues. Most of these are "Class C" security issues, meaning that they require prior valid login for privilege escalation. Some also require additional database conditions to be true in order to be exploited. One fix below breaks backwards compatibility in a way that complies with our documentation but not with past behavior.

Summaries below provided by Noah Misch and Tom Lane.

Vulnerability during "make check"

CVE-2014-0067 PostgreSQL: Vulnerability during "make check"

This issue is not fixed in this release. It was fixed in later releases. Please update to the very latest minor version in order to have this issue fully patched.

We are posting it in the interests of transparency, and so that database administrators and security staff will take the appropriate measures to secure their servers.

Explanation

The PostgreSQL Global Development Group security team has discovered a vulnerability in the scripts that orchestrate PostgreSQL test suites that validate the functionality of the PostgreSQL binaries. While a test suite is running, a user with interactive access to the system can hijack the operating system user account running the suite. Only users who run "make check" on a system they share with untrusted users are at risk. A future set of update releases will fix this vulnerability, though there will be no need to reinstall existing deployments. In the meantime, users are advised to run the test suites only on non-shared systems or under operating system user accounts dedicated to the task of running test suites.

This vulnerability arises from the test scripts' use of "initdb" to create a PostgreSQL database cluster permitting local "trust" authentication. User-crafted workflows doing the same will exhibit the same vulnerability. We recommend studying automated usage of initdb in your own software. If a procedure in question could run on a system shared with untrusted users, follow the same precautions around that procedure as for the PostgreSQL test suites. The fix for PostgreSQL itself will establish a secure pattern for automating initdb, which you can later adopt.

On Unix-like platforms the attacker needs to be able to reach the server's socket file, so the risk depends on where the platform places the socket file and whether there are filesystem permissions protections in place. On Windows, the server opens a locally-accessible TCP socket, so there is no possibility of ameliorating the risk through filesystem permissions.

The changes required to make this situation safer are expected to be somewhat invasive and might break user-crafted testing workflows. Therefore, the PostgreSQL project will not actually be supplying a fix on 20-Feb, merely announcing that there is a problem and recommending that users not use "make check" on machines shared with untrusted users. Suitable changes to the regression testing setup will subsequently be debated publicly and can be expected to be incorporated in future releases.

The PostgreSQL project thanks Noah Misch for reporting this problem.

SET ROLE bypasses lack of ADMIN OPTION

CVE-2014-0060 PostgreSQL: SET ROLE bypasses lack of ADMIN OPTION

This change will break backwards compatibility for users who were expecting the prior, broken behavior. The new behavior is in compliance with the documentation.

Explanation

Enforce ADMIN OPTION restrictions.

Granting a role without ADMIN OPTION is supposed to prevent the grantee from adding or removing members from the granted role. Issuing SET ROLE before the GRANT bypassed that, because the role itself had an implicit right to add or remove members. This issue was fixed by recognizing that implicit right only when the session user matches the current role. Additionally, do not recognize it during a security-restricted operation or during execution of a SECURITY DEFINER function. The restriction on SECURITY DEFINER is not security-critical. However, it seems best for a user testing his or her own SECURITY DEFINER function to see the same behavior others will see. Affects all supported versions back to 8.4.

The SQL standards do not conflate roles and users as PostgreSQL does; only SQL roles have members, and only SQL users initiate sessions. An application using PostgreSQL users and roles as SQL users and roles will never attempt to grant membership in the role that is the session user, so the implicit right to add or remove members will never arise.

The security impact was mostly that a role member could revoke access from others, contrary to the wishes of the role member's grantor. Unapproved role member additions are less notable, because the member can still largely achieve that by creating a view or a SECURITY DEFINER function.

The PostgreSQL project thanks Noah Misch and Jonas Sundman for reporting this problem.

Language validators are accessible for everyone

CVE-2014-0061 PostgreSQL: Privilege escalation via explicit calls to validator functions

Explanation

PostgreSQL procedural languages (PLs) normally provide a "validator" function that performs creation-time checking of syntax etc. for functions written in that language. These validator functions can be called directly from SQL, too, which is intended to allow post-facto checking of existing function definitions. However, unexpected and possibly insecure results could be obtained by feeding the text of a function defined in one language to the validator for another language. Moreover, in many languages the validator might perform some limited amount of code execution, opening the possibility of an attacker executing code without permission. The security impact is thus that an authenticated database user might be able to escalate his or her privileges.

The fix will cause validator functions to throw an error when used against a function defined in another language, or against a function the current user doesn't have permissions to call.

While the PostgreSQL project will fix the validator functions in PLs distributed with PostgreSQL, the same two-line fix will be needed in validator functions of PLs developed externally. There are many such extensions and we cannot be certain that all of their developers will respond promptly.

The PostgreSQL project thanks Andres Freund for reporting this problem.

Race condition in CREATE INDEX allows for privilege escalation

CVE-2014-0062 PostgreSQL: Race condition in CREATE INDEX allows for privilege escalation

Description

CREATE INDEX, and some ALTER TABLE statements, did multiple independent lookups of the table the index is supposed to be created on. Concurrent creation or deletion of another table of the same name (but in a different schema) might cause some of these lookups to find one table and some the other table. This allows effects such as creating an index on a table one doesn't own, thus exposing data to the calling user that should not be able to access. This vulnerability exists in all affected versions, but is more easily exploited in 9.2 and 9.3.

The PostgreSQL project thanks Andres Freund for reporting this problem.

Potential Buffer Overruns in Datetime Input/Output

• CVE-2014-0063 PostgreSQL: Potential buffer overruns in datetime input/output

Descriptions

Many functions use the MAXDATELEN constant to size a buffer for parsing or displaying a datetime value. However, the buffer was much too small for the longest possible interval output and slightly too small for certain valid timestamp inputs, particularly input with a long timezone name. Inputs that were too long would be rejected needlessly, while outputs that were too long would result in stack corruption, which could crash the server and could be exploitable for arbitrary code execution.

The PostgreSQL project thanks Daniel Schüssler for reporting this problem.

Buffer overflow in path_in()

• CVE-2014-0064 PostgreSQL: Potential buffer overruns due to integer overflow in size calculations

Description

Predict integer overflow to avoid buffer overruns.

Several functions, mostly type input functions, calculated an allocation size such that the calculation wrapped to a small positive value when arguments implied a sufficiently-large requirement. Writes past the end of the inadvertent small allocation followed shortly thereafter. Coverity Scan identified the path_in() vulnerability; code inspection led to the rest. In passing, add check_stack_depth() to prevent stack overflow in related functions.

Affects all supported versions back to 8.4. The non-comment hstore changes touch code that did not exist in 8.4, so that part stops at 9.0.

Potential Buffer Overruns of Fixed-Size Buffers

• CVE-2014-0065 PostgreSQL: Potential buffer overruns of fixed-size buffers

Explanation

Coverity Scan identified a number of places in which it could not prove that a string being copied into a fixed-size buffer would fit. We believe that most, perhaps all of these, are in fact safe or are copying data that is coming from a trusted source so that any overrun is not really a security issue. Nonetheless it seems prudent to forestall any risk by using strlcpy() and similar functions.

The PostgreSQL project thanks Peter Eisentraut and Jozef Mlich for reporting this problem.

Potential null pointer dereference crash when crypt(3) returns NULL

CVE-2014-0066 PostgreSQL: Potential null pointer dereference crash when crypt(3) returns NULL

Explanation

The chkpass extension uses the standard crypt() library function, which is defined to return NULL on failure, but it was not checking for NULL before using the result. The main practical case in which this could be an issue is if libc is configured to refuse to execute unapproved hashing algorithms ("FIPS mode").

The PostgreSQL project thanks Honza Horak for reporting this problem.