Bug 825995 - (CVE-2012-2655) CVE-2012-2655 postgresql: Ability of database owners to install procedural languages via CREATE LANGUAGE found unsafe (DoS)
CVE-2012-2655 postgresql: Ability of database owners to install procedural la...
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,public=20120530,reported=2...
: Security
Depends On: 826606 830723 830724 830725 830726
Blocks: 816965
  Show dependency treegraph
 
Reported: 2012-05-29 05:46 EDT by Jan Lieskovsky
Modified: 2015-11-24 10:03 EST (History)
4 users (show)

See Also:
Fixed In Version: postgresql 9.1.4, postgresql 9.0.8, postgresql 8.4.12, postgresql 8.3.19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-25 14:53:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Lieskovsky 2012-05-29 05:46:20 EDT
A security flaw was found in the way PostgreSQL, an advanced Object-Relational database management system (DBMS), performed inclusion of additional procedural language plug-ins support into PostgreSQL server. Previously, database administrators were allowed to install trusted procedural languages into their databases and the owner of such procedural language function were allowed to execute ALTER FUNCTION statement. If a procedural language plug-in was enabled on the particular database, an authenticated database administrator could use this flaw to cause denial of service (PostgreSQL server crash) by adding SECURITY DEFINER or SET attributes to such a handler function.
Comment 2 Jan Lieskovsky 2012-05-31 11:13:37 EDT
Public via:
[1] http://archives.postgresql.org/pgsql-hackers/2012-05/msg01471.php
Comment 3 Jan Lieskovsky 2012-05-31 11:53:58 EDT
This issue did NOT affect the version of the postgresql package, as shipped with Red Hat Enterprise Linux 5.

In PostgreSQL 8.1.23 version:
http://www.postgresql.org/docs/8.1/static/

only superusers are allowed to install procedural languages. Thus while the bug exists in that version too, the superuser requirement / condition is making it not to be a security flaw for this particular version.

--

This issue affects the version of the postgresql84 package, as shipped
with Red Hat Enterprise Linux 5.

--

This issue affects the version of the postgresql package, as shipped
with Red Hat Enterprise Linux 6.

--

This issue affects the versions of the postgresql package, as shipped with Fedora release of 15 and 16.
Comment 5 Jan Lieskovsky 2012-05-31 11:58:45 EDT
Created postgresql tracking bugs for this issue

Affects: fedora-all [bug 826606]
Comment 7 Tom Lane 2012-05-31 13:49:58 EDT
(In reply to comment #3)
> This issue affects the versions of the postgresql and postgresql84 packages,
> as shipped with Red Hat Enterprise Linux 5.

Actually I don't think this is a security issue for Postgres 8.1 (which is what is in the RHEL5 postgresql package).  In 8.1, non-superusers can't create procedural languages.  So while the bug exists there, it can only be triggered by a superuser; which makes it not a security issue, because superusers ought to know better (and have plenty of better ways than this to mess up the server, anyway).

We do need to fix it in postgresql84, as well as RHEL6 postgresql.
Comment 9 Jan Lieskovsky 2012-06-04 08:44:15 EDT
(In reply to comment #7)
> (In reply to comment #3)
> > This issue affects the versions of the postgresql and postgresql84 packages,
> > as shipped with Red Hat Enterprise Linux 5.
> 
> Actually I don't think this is a security issue for Postgres 8.1 (which is
> what is in the RHEL5 postgresql package).  In 8.1, non-superusers can't
> create procedural languages.  So while the bug exists there, it can only be
> triggered by a superuser; which makes it not a security issue, because
> superusers ought to know better (and have plenty of better ways than this to
> mess up the server, anyway).
> 
> We do need to fix it in postgresql84, as well as RHEL6 postgresql.

Thank you for the correction, Tom.
Comment 14 errata-xmlrpc 2012-06-25 14:13:44 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5
  Red Hat Enterprise Linux 6

Via RHSA-2012:1037 https://rhn.redhat.com/errata/RHSA-2012-1037.html

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