|Summary:||CVE-2009-0922 postgresql: potential DoS due to conversion functions|
|Product:||[Other] Security Response||Reporter:||Vincent Danen <vdanen>|
|Component:||vulnerability||Assignee:||Red Hat Product Security <security-response-team>|
|Status:||CLOSED ERRATA||QA Contact:|
|Version:||unspecified||CC:||azelinka, jlieskov, kreilly, kseifried, kvolny, mjc, overholt, tgl|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-10-25 18:46:39 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||525282, 525283, 525284, 525285, 812238|
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 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