Bug 559259 (CVE-2010-0442) - CVE-2010-0442 postgresql: substring() negative length argument buffer overflow
Summary: CVE-2010-0442 postgresql: substring() negative length argument buffer overflow
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2010-0442
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL: http://intevydis.blogspot.com/2010/01...
Whiteboard:
Depends On: 559194 559195 559661 586056 586057 586058 586059 589541 589543 812237
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-27 15:33 UTC by Tomas Hoger
Modified: 2019-09-29 12:34 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-26 15:09:37 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2010:0427 normal SHIPPED_LIVE Moderate: postgresql security update 2010-05-19 15:48:23 UTC
Red Hat Product Errata RHSA-2010:0428 normal SHIPPED_LIVE Moderate: postgresql security update 2010-05-19 16:15:45 UTC
Red Hat Product Errata RHSA-2010:0429 normal SHIPPED_LIVE Moderate: postgresql security update 2010-05-19 16:29:57 UTC

Description Tomas Hoger 2010-01-27 15:33:26 UTC
Intevydis reported a buffer overflow in PostgreSQL's implementation of substring() function when called with negative length argument:

 http://intevydis.blogspot.com/2010/01/postgresql-8023-bitsubstr-overflow.html

Following query triggers overflow / crash:

 select substring(B'10101010101010101010101010101010101010101010101',33,-15);

Comment 2 Vincent Danen 2010-01-27 20:54:30 UTC
Tom noted this in bug #559194#c1:

"We didn't consider this especially serious upstream, since AFAICS it'd be
difficult to exploit it for anything more than a crash --- an attacker wouldn't
have much control over what got copied where."

We would need to determine whether or not this just kills the current active connection, or whether it kills all connections to the database.  If it is the former, and there is no chance of anything more than a crash, then I don't think we would consider it any more security relevant than typing '\q' at the pgsql command prompt.

Tom, would you happen to know the answer to the above by chance?

Comment 3 Vincent Danen 2010-01-27 21:00:41 UTC
Sorry for the noise, I just saw this:

| LOG:  server process (PID 24968) was terminated by signal 11: Segmentation fault
| LOG:  terminating any other active server processes
| WARNING:  terminating connection because of crash of another server process


looks like it would indeed take out any other active processes.

Comment 4 Josh Bressers 2010-01-27 22:03:17 UTC
Tom,

Do you know if this affects all versions of postgresql? I just took a look at the version in RHEL3, the logic is different, I've not tried a reproducer yet (I need to get postgresql running there first).

Thanks.

Comment 5 Tom Lane 2010-01-27 22:09:10 UTC
Yeah, that logic was the same all the way back to PG 7.1.

Comment 6 Tom Lane 2010-01-27 22:11:58 UTC
(In reply to comment #2)
> We would need to determine whether or not this just kills the current active
> connection, or whether it kills all connections to the database.

In general, any process crash kills all connections to a PG database --- part of the crash recovery strategy is to kill all active connections and restart.  In some cases that would be overly conservative, but nobody upstream is particularly interested in trying to analyze when it might be safe to do less.

Comment 7 Vincent Danen 2010-01-27 23:48:34 UTC
This has been assigned the name CVE-2010-0442.

Comment 17 errata-xmlrpc 2010-05-19 15:48:35 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 18 errata-xmlrpc 2010-05-19 16:15:57 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 19 errata-xmlrpc 2010-05-19 16:30:00 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


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