[HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL(fwd)
Here's yet another. He claims malicious code can be run on the server
with this one.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com http://www.cloudninegifts.com
http://www.meanstreamradio.com http://www.unknown-artists.com
==
-- Forwarded message --
Date: Tue, 20 Aug 2002 14:28:49 +
From: Sir Mordred The Traitor <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
//@(#)Mordred Labs advisory 0x0003
Release data: 20/08/02
Name: Buffer overflow in PostgreSQL
Versions affected: all versions
Risk: high
--[ Description:
...PostgreSQL is a sophisticated Object-Relational DBMS,
supporting almost all SQL constructs, including subselects,
transactions, and user-defined types and functions. It is the
most advanced open-source database available anywhere...blah...blah...
For more info check out this link:
http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS
There exists a heap buffer overflow in a repeat(text, integer) function,
which
allows an attacker to execute malicious code.
--[ Details:
Upon invoking a repeat() function, a
src/backend/utils/adt/oracle_compat.c::repeat() function
will gets called which suffers from a buffer overflow.
--[ How to reproduce:
psql> select repeat('xxx',1431655765);
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
--[ Solution
Do you still running postgresql? ...Can't believe that...
If so, execute the following command as a root: "killall -9 postmaster",
and wait until the patch will be available.
This letter has been delivered unencrypted. We'd like to remind you that
the full protection of e-mail correspondence is provided by S-mail
encryption mechanisms if only both, Sender and Recipient use S-mail.
Register at S-mail.com: http://www.s-mail.com/inf/en
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Vince Vielhaber wrote: > > Here's yet another. He claims malicious code can be run on the server > with this one. > --[ Solution > > Do you still running postgresql? ...Can't believe that... > If so, execute the following command as a root: "killall -9 postmaster", > and wait until the patch will be available. You've got to love this last part. ;-) This has the attitude of "Oh, look at me, I found a bug. Let me publicize it and get more attention. Aren't you proud of me?" -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Dann Corbit wrote: > > -Original Message- > > From: Neil Conway [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, August 20, 2002 1:44 PM > > To: Vince Vielhaber > > Cc: [EMAIL PROTECTED] > > Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: > > Buffer overflow in PostgreSQL (fwd) > > > > > > Vince Vielhaber <[EMAIL PROTECTED]> writes: > > > Here's yet another. > > > > Should someone from the core team perhaps get in contact with > > this guy and ask if he could get in contact with the > > development team before publicizing any further security > > holes? AFAIK that is standard operating procedure in most cases... > > As long as we continue to find out about them, I would just let him work > away. > He is clearly an excellent tester, and if you had to hire him it would > be very expensive. > > As long as he is producing results of such great value, I think it is > wonderful. Yea, someone please contact him and tell him to keep going. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Neil Conway wrote: > Tom Lane <[EMAIL PROTECTED]> writes: > > Neil Conway <[EMAIL PROTECTED]> writes: > > > + /* Check for integer overflow */ > > > + if (tlen / slen != count) > > > + elog(ERROR, "Requested buffer is too large."); > > > > What about slen == 0? > > Good point -- that wouldn't cause incorrect results or a security > problem, but it would reject input that we should really accept. > > Revised patch is attached. > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL
Patch applied. Thanks. --- Neil Conway wrote: > Tom Lane <[EMAIL PROTECTED]> writes: > > Neil Conway <[EMAIL PROTECTED]> writes: > > > + /* Check for integer overflow */ > > > + if (tlen / slen != count) > > > + elog(ERROR, "Requested buffer is too large."); > > > > What about slen == 0? > > Good point -- that wouldn't cause incorrect results or a security > problem, but it would reject input that we should really accept. > > Revised patch is attached. > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber <[EMAIL PROTECTED]> writes:
> Here's yet another. He claims malicious code can be run on the server
> with this one.
regression=# select repeat('xxx',1431655765);
server closed the connection unexpectedly
This is probably caused by integer overflow in calculating the size of
the repeat's result buffer. It'd take some considerable doing to create
an arbitrary-code exploit, but perhaps could be done. Anyone want to
investigate a patch? I think we likely need something like
bufsize = input_length * repeats;
+ /* check for overflow in multiplication */
+ if (bufsize / repeats != input_length)
+ elog(ERROR, "repeat result too long");
but I haven't thought it through in detail.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber <[EMAIL PROTECTED]> writes: > Where do we check that this: > result = (text *) palloc(tlen); > is even successful? palloc elogs if it can't allocate the space; it's unlike malloc in that respect. I believe it also has a guard to reject requests > 1Gb, so I think it's reasonably proof against internal arithmetic overflows. This problem is strictly repeat's error, not palloc's. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Tom Lane <[EMAIL PROTECTED]> writes:
> Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > Here's yet another. He claims malicious code can be run on the server
> > with this one.
>
> regression=# select repeat('xxx',1431655765);
> server closed the connection unexpectedly
>
> This is probably caused by integer overflow in calculating the size of
> the repeat's result buffer. It'd take some considerable doing to create
> an arbitrary-code exploit, but perhaps could be done. Anyone want to
> investigate a patch?
This seems to fix the problem:
nconway=# select repeat('xxx',1431655765);
ERROR: Requested buffer is too large.
It uses the logic you suggested. Just a quick and dirty fix, I may
have missed something... The patch applies cleanly to both CVS HEAD
and the 7.2 stable branch.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.38
diff -c -r1.38 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c 20 Jun 2002 20:51:45 - 1.38
--- src/backend/utils/adt/oracle_compat.c 20 Aug 2002 20:27:21 -
***
*** 997,1002
--- 997,1006
slen = (VARSIZE(string) - VARHDRSZ);
tlen = (VARHDRSZ + (count * slen));
+ /* Check for integer overflow */
+ if (tlen / slen != count)
+ elog(ERROR, "Requested buffer is too large.");
+
result = (text *) palloc(tlen);
VARATT_SIZEP(result) = tlen;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Neil Conway <[EMAIL PROTECTED]> writes: > + /* Check for integer overflow */ > + if (tlen / slen != count) > + elog(ERROR, "Requested buffer is too large."); What about slen == 0? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Vince Vielhaber <[EMAIL PROTECTED]> writes: > Here's yet another. Should someone from the core team perhaps get in contact with this guy and ask if he could get in contact with the development team before publicizing any further security holes? AFAIK that is standard operating procedure in most cases... Second, it might be worth pushing a 7.2.2 release containing the fix for this bug, as well as the datetime problem. If that sounds reasonable to the people who have to do the most work on a new release (e.g. Marc), I can volunteer to backport a fix for the datetime problem. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
> -Original Message- > From: Neil Conway [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 20, 2002 1:44 PM > To: Vince Vielhaber > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: > Buffer overflow in PostgreSQL (fwd) > > > Vince Vielhaber <[EMAIL PROTECTED]> writes: > > Here's yet another. > > Should someone from the core team perhaps get in contact with > this guy and ask if he could get in contact with the > development team before publicizing any further security > holes? AFAIK that is standard operating procedure in most cases... As long as we continue to find out about them, I would just let him work away. He is clearly an excellent tester, and if you had to hire him it would be very expensive. As long as he is producing results of such great value, I think it is wonderful. > Second, it might be worth pushing a 7.2.2 release containing > the fix for this bug, as well as the datetime problem. If > that sounds reasonable to the people who have to do the most > work on a new release (e.g. Marc), I can volunteer to > backport a fix for the datetime problem. Bugs that cause a catastrophic error (e.g. "crash" of the database engine, causing loss of data) should have the highest priority. Call them category zero. Bugs that cause incorrect results should have the next highest priority. Call them category one. Bugs that are minor annoyances (e.g. "appearance" such as a misspelled word in a help file) should be low priority. Bugs that are only suggestions for improvements should have the lowest priority. All known category zero and one bugs should be fixed before each and every new release. IMO-YMMV. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Tom Lane <[EMAIL PROTECTED]> writes: > Neil Conway <[EMAIL PROTECTED]> writes: > > + /* Check for integer overflow */ > > + if (tlen / slen != count) > > + elog(ERROR, "Requested buffer is too large."); > > What about slen == 0? Good point -- that wouldn't cause incorrect results or a security problem, but it would reject input that we should really accept. Revised patch is attached. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC Index: src/backend/utils/adt/oracle_compat.c === RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v retrieving revision 1.38 diff -c -r1.38 oracle_compat.c *** src/backend/utils/adt/oracle_compat.c 20 Jun 2002 20:51:45 - 1.38 --- src/backend/utils/adt/oracle_compat.c 20 Aug 2002 20:51:20 - *** *** 997,1002 --- 997,1006 slen = (VARSIZE(string) - VARHDRSZ); tlen = (VARHDRSZ + (count * slen)); + /* Check for integer overflow */ + if (slen != 0 && count != 0 && tlen / slen != count) + elog(ERROR, "Requested buffer is too large."); + result = (text *) palloc(tlen); VARATT_SIZEP(result) = tlen; ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
> Should someone from the core team perhaps get in contact with this guy > and ask if he could get in contact with the development team before > publicizing any further security holes? AFAIK that is standard > operating procedure in most cases... > > Second, it might be worth pushing a 7.2.2 release containing the fix > for this bug, as well as the datetime problem. If that sounds > reasonable to the people who have to do the most work on a new release > (e.g. Marc), I can volunteer to backport a fix for the datetime > problem. It'd be better to contact the dude and get all his bugs out of him, fix them all and issue a 7.2.2 with all the fixes. I think this is now essential - people will be using 7.2 series for ages even after the 7.3 release... Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)
Neil Conway <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>
> > Vince Vielhaber <[EMAIL PROTECTED]> writes:
> > > Here's yet another. He claims malicious code can be run on the server
> > > with this one.
> >
> > regression=# select repeat('xxx',1431655765);
> > server closed the connection unexpectedly
> >
> > This is probably caused by integer overflow in calculating the size of
> > the repeat's result buffer. It'd take some considerable doing to create
> > an arbitrary-code exploit, but perhaps could be done. Anyone want to
> > investigate a patch?
>
> This seems to fix the problem:
No, no it does not :-)
Tom pointed out some obvious braindamage in my previous patch. I've
attached a revised version.
Cheers,
Neil
--
Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC
Index: src/backend/utils/adt/oracle_compat.c
===
RCS file: /var/lib/cvs/pgsql-server/src/backend/utils/adt/oracle_compat.c,v
retrieving revision 1.37
diff -c -r1.37 oracle_compat.c
*** src/backend/utils/adt/oracle_compat.c 8 Jan 2002 17:03:41 - 1.37
--- src/backend/utils/adt/oracle_compat.c 21 Aug 2002 21:03:59 -
***
*** 997,1002
--- 997,1012
slen = (VARSIZE(string) - VARHDRSZ);
tlen = (VARHDRSZ + (count * slen));
+ /* Check for integer overflow */
+ if (slen != 0 && count != 0)
+ {
+ int check = count * slen;
+ int check2 = check + VARHDRSZ;
+
+ if ((check / slen) != count || check2 <= check)
+ elog(ERROR, "Requested buffer is too large.");
+ }
+
result = (text *) palloc(tlen);
VARATT_SIZEP(result) = tlen;
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
