Bug 546321 - (CVE-2009-4136) CVE-2009-4136 postgresql: SQL privilege escalation via modifications to session-local state
CVE-2009-4136 postgresql: SQL privilege escalation via modifications to sessi...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,source=redhat,reported=200...
: Security
Depends On: 552617 586056 586057 586058 586059 589541 589543 812237
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-10 11:37 EST by Tom Lane
Modified: 2013-07-02 23:25 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-26 11:09:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tom Lane 2009-12-10 11:37:28 EST
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-14 21:15:00 EST
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 12:11:05 EST
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-17 23:36:16 EST
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-17 23:39:35 EST
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 11:48:46 EDT
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 12:16:03 EDT
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 12:30:05 EDT
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

Note You need to log in before you can comment on or make changes to this bug.