Bug 559259 (CVE-2010-0442)

Summary: CVE-2010-0442 postgresql: substring() negative length argument buffer overflow
Product: [Other] Security Response Reporter: Tomas Hoger <thoger>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: bressers, devrim, dkovalsk, kreilly, kvolny, mjc, tgl, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://intevydis.blogspot.com/2010/01/postgresql-8023-bitsubstr-overflow.html
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-05-26 15:09:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 559194, 559195, 559661, 586056, 586057, 586058, 586059, 589541, 589543, 812237    
Bug Blocks:    

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