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);
Looks like Tom patched this upstream few days ago: http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=75dea10196c31d98d98c0bafeeb576ae99c09b12 http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=b15087cb39ca9e4bde3c8920fcee3741045d2b83
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?
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.
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.
Yeah, that logic was the same all the way back to PG 7.1.
(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.
This has been assigned the name CVE-2010-0442.
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
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
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
(In reply to comment #1) > Looks like Tom patched this upstream few days ago: > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=75dea10196c31d98d98c0bafeeb576ae99c09b12 > http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=b15087cb39ca9e4bde3c8920fcee3741045d2b83 Looks like these links are no longer valid after final CVS->git migration upstream. Relevant fix is: http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/varbit.c.diff?r1=1.61;r2=1.62;f=h or http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=e4a6ebf7dece1481b1432c8ac43124487bebf3d9