Bug 546321 (CVE-2009-4136)

Summary: CVE-2009-4136 postgresql: SQL privilege escalation via modifications to session-local state
Product: [Other] Security Response Reporter: Tom Lane <tgl>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: hhorak, jlieskov, kreilly, kvolny, mjc, security-response-team, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-26 15:09:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 552617, 586056, 586057, 586058, 586059, 589541, 589543, 812237    
Bug Blocks:    

Description Tom Lane 2009-12-10 16:37:28 UTC
Description of problem:
All currently shipped versions of PostgreSQL are vulnerable to a new type of attack pointed out by Gurjeet Singh.  The scenario is similar to CVE-2007-6600 in that an attacker must be an authenticated user so that he can create a table with attached indexes, which reference functions he has created.   Subsequent maintenance operations performed by database superusers will then have to execute those functions.  In -6600 the threat was simply to acquire the caller's privileges directly.  However, another possibility is that the index function can modify session-local state in a way that will subvert later operations in the same session.  Examples include changing the search_path so that an attacker-created function will be invoked instead of the intended one, or replacing an existing prepared statement with a new one containing code of the attacker's choosing.  There have up to now been only very limited security controls on most session-local state, so it was easy to think of possible attack vectors once the basic issue was recognized.

This attack is less dangerous than -6600 since it only succeeds if the calling session does something subvert-able later.  In particular it's not clear that there's any major risk for automatic vacuum operations.  But superusers who do manual vacuuming or reindexing are clearly at risk.

Upstream versions due to be announced Monday 12-14 contain assorted fixes meant to mitigate this scenario.

Comment 14 Vincent Danen 2009-12-15 02:15:00 UTC
This is now public and has been addressed upstream in 8.4.2, 8.3.9, 8.2.15, 8.1.19, 8.0.23, and 7.4.27, as per http://www.postgresql.org/support/security.html .

Comment 18 Fedora Update System 2009-12-16 17:11:05 UTC
postgresql-8.3.9-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/postgresql-8.3.9-1.fc11

Comment 19 Fedora Update System 2009-12-18 04:36:16 UTC
postgresql-8.3.9-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2009-12-18 04:39:35 UTC
postgresql-8.4.2-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 26 errata-xmlrpc 2010-05-19 15:48:46 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 3

Via RHSA-2010:0427 https://rhn.redhat.com/errata/RHSA-2010-0427.html

Comment 27 errata-xmlrpc 2010-05-19 16:16:03 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2010:0428 https://rhn.redhat.com/errata/RHSA-2010-0428.html

Comment 28 errata-xmlrpc 2010-05-19 16:30:05 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0429 https://rhn.redhat.com/errata/RHSA-2010-0429.html