Bug 559194 - PostgreSQL 8.0.23 bitsubstr overflow
PostgreSQL 8.0.23 bitsubstr overflow
Status: CLOSED DUPLICATE of bug 586059
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: postgresql (Show other bugs)
All Linux
high Severity high
: rc
: ---
Assigned To: Tom Lane
Depends On:
Blocks: 559195 CVE-2010-0442
  Show dependency treegraph
Reported: 2010-01-27 07:23 EST by David Kovalsky
Modified: 2014-03-31 19:45 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 559195 (view as bug list)
Last Closed: 2010-04-26 14:16:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Kovalsky 2010-01-27 07:23:29 EST
I've seen this in my RSS reader:

So I figured I might try it on RHEL5:

.qa.[root@i386-5s-3-m1 ~]# rpm -q postgresql

.qa.[root@i386-5s-3-m1 ~]# su - postgres

-bash-3.2$ psql 
Welcome to psql 8.1.11, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands    
       \? for help with psql commands   
       \g or terminate with semicolon to execute query
       \q to quit                                     

postgres=# select version();
 PostgreSQL 8.1.11 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)
(1 row)

postgres=# select substring(B'10101010101010101010101010101010101010101010101',33,-15);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Succeeded.

The log shows:
LOG:  server process (PID 14481) was terminated by signal 11
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  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.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted at 2010-01-27 07:08:08 EST
LOG:  checkpoint record is at 0/33A70C
LOG:  redo record is at 0/33A70C; undo record is at 0/0; shutdown TRUE
LOG:  next transaction ID: 565; next OID: 10794
LOG:  next MultiXactId: 1; next MultiXactOffset: 0
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/33A750
LOG:  redo is not required
LOG:  database system is ready
LOG:  transaction ID wrap limit is 2147484146, limited by database "postgres"

Not sure if this is relevant when ran with limited privileges, nevertheless, one shouldn't be able to kill/crash active database process.
Comment 1 Tom Lane 2010-01-27 10:21:47 EST
Huh, those people must be reading the Postgres mailing lists:


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.
Comment 5 Ludek Smid 2010-03-11 04:56:49 EST
Since it is too late to address this issue in RHEL 5.5, it has been proposed for RHEL 5.6.  Contact your support representative if you need to escalate this issue.
Comment 6 Tomas Hoger 2010-03-22 05:43:29 EDT
(In reply to comment #1)

> an attacker wouldn't have much control over what got copied where.    

An attacker has control over prefix of what (taken from SQL query, specified by attacker as a stream of 0s and 1s, that is turned into bytes), where is somewhat predictable (after the buffer allocated on heap), the biggest problem is how much, as this is integer underflow, resulting in a long memory copy triggering SEGV before overwritten memory is used.
Comment 7 Jan Lieskovsky 2010-04-26 14:16:58 EDT

*** This bug has been marked as a duplicate of bug 586059 ***

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