Bug 488156 (CVE-2009-0922) - CVE-2009-0922 postgresql: potential DoS due to conversion functions
Summary: CVE-2009-0922 postgresql: potential DoS due to conversion functions
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-0922
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 525282 525283 525284 525285 812238
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-02 21:49 UTC by Vincent Danen
Modified: 2019-09-29 12:28 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-25 18:46:39 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1067 normal SHIPPED_LIVE Moderate: Red Hat Application Stack v2.3 security and enhancement update 2009-05-26 17:06:06 UTC
Red Hat Product Errata RHSA-2009:1484 normal SHIPPED_LIVE Moderate: postgresql security update 2009-10-07 16:22:44 UTC

Description Vincent Danen 2009-03-02 21:49:04 UTC
A stack overflow was found in how PostgreSQL handles conversion encoding.  This could allow an authenticated user to kill connections to the PostgreSQL server for a small amount of time, which could interupt transactions by other users/clients.

The original report is here:

http://archives.postgresql.org/pgsql-bugs/2009-02/msg00172.php

Upstream has a patch for this issue that causes the server to crash in a different way (core dump due to abort() rather than core dump due to stack overflow), but it sounds like they are still looking for a better fix.

Comment 8 Vincent Danen 2009-03-09 20:33:30 UTC
On a second look, the postmaster and postgres logging processes are not killed, but this does impact other connections as anyone attempting to interact with the db immediately after the crash will get "The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory."  After a brief wait, however, without restarting the client, commands can be executed.

Comment 9 Tom Lane 2009-03-11 17:43:44 UTC
BTW, has anyone assigned a CVE number to this?  Upstream will be preparing a release tomorrow, and it'd be good to cite the number if there is one.

Comment 10 Vincent Danen 2009-03-11 18:01:02 UTC
Not that I have seen, but I'll see if I can find one.

Comment 11 Vincent Danen 2009-03-11 18:12:36 UTC
For reference, since I didn't know it before, this is also filed in Debian's BTS:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517405

Doesn't look like a CVE request was ever done.

Comment 12 Tom Lane 2009-03-17 17:03:56 UTC
Okay, I did one ... it's CVE-2009-0922

Comment 13 Jan Lieskovsky 2009-03-17 17:09:25 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0922 to
the following vulnerability:

PostgreSQL 8.3.6 allows remote authenticated users to cause a denial
of service (stack consumption) via mismatched encoding conversion
requests.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0922
http://www.openwall.com/lists/oss-security/2009/03/11/4
http://archives.postgresql.org/pgsql-bugs/2009-02/msg00172.php
http://archives.postgresql.org//pgsql-bugs/2009-02/msg00176.php
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517405

Comment 14 Tom Lane 2009-03-17 17:37:26 UTC
Mitre's original description is a bit wrong (not their fault, I sent them only limited info).  Here is the more complete description I just sent:

PostgreSQL allows remote authenticated users to cause a momentary denial
of service (crash due to stack consumption) when there is a failure to
convert a localized error message to the client-specified encoding.
In releases 8.3.6, 8.2.12, 8.1.16. 8.0.20, and 7.4.24, a trivial
misconfiguration is sufficient to provoke a crash.  In older releases
it is necessary to select a locale and client encoding for which
specific messages fail to translate, and so a given installation may or
may not be vulnerable depending on the administrator-determined locale
setting.

Releases 8.3.7, 8.2.13, 8.1.17, 8.0.21, and 7.4.25 are secure against
all known variants of this issue.

Comment 15 Fedora Update System 2009-03-21 23:44:32 UTC
postgresql-8.3.7-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/postgresql-8.3.7-1.fc10

Comment 16 Fedora Update System 2009-03-21 23:44:41 UTC
postgresql-8.3.7-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/postgresql-8.3.7-1.fc9

Comment 17 Fedora Update System 2009-03-23 15:53:40 UTC
postgresql-8.3.7-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 18 Fedora Update System 2009-03-23 15:58:35 UTC
postgresql-8.3.7-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Vincent Danen 2009-03-26 20:21:08 UTC
The Red Hat Security Response Team has rated this issue as having low security
impact, a future update may address this flaw. More information regarding
issue severity can be found here:
http://www.redhat.com/security/updates/classification/

Comment 23 errata-xmlrpc 2009-05-26 17:06:24 UTC
This issue has been addressed in following products:

  Red Hat Web Application Stack for RHEL 5

Via RHSA-2009:1067 https://rhn.redhat.com/errata/RHSA-2009-1067.html

Comment 25 Tom Lane 2009-09-23 22:39:19 UTC
After some investigation, it appears that postgresql 7.3.21 as shipped in RHEL-3 is not vulnerable to this issue.  The recursive error condition can't arise, partly because the error handling logic is quite a bit different/simpler, and partly because no translation is shipped anyway for the critical "character has no equivalent" message.  Also, the problem of encoding conversion functions throwing Assert aborts when misused (which was one component of the original issue) isn't an issue for RHEL-3 because Asserts aren't enabled in our builds.

Comment 27 errata-xmlrpc 2009-10-07 16:22:52 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2009:1484 https://rhn.redhat.com/errata/RHSA-2009-1484.html

Comment 28 Kurt Seifried 2011-10-25 18:46:39 UTC
This issue has been addressed in:

Red Hat Application Stack v2 for Enterprise Linux (v.5) 	RHSA-2009:1067
Red Hat Enterprise Linux version 4 	RHSA-2009:1484
Red Hat Enterprise Linux version 5 	RHSA-2009:1484


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