Red Hat Bugzilla – Bug 559194
PostgreSQL 8.0.23 bitsubstr overflow
Last modified: 2014-03-31 19:45:11 EDT
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
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)
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.
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.
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.
(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.
*** This bug has been marked as a duplicate of bug 586059 ***