Thread: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
@(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
From
Vince Vielhaber
Date:
And another one. Sure would be nice if shit-for-brains would mention it to us first. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 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 15:01:34 +0000 From: Sir Mordred The Traitor <mordred@s-mail.com> To: bugtraq@securityfocus.com Subject: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. //@(#) Mordred Labs advisory 0x0004 Release data: 20/08/02 Name: Two buffer overflows in PostgreSQL Versions affected: all versions Conditions: multibyte support Risk: average --[ Description: I guess all of you already hear about the PostgreSQL. If not, try to visit http://www.postgresql.org/idocs/index.php?preface.html#INTRO-WHATIS. There are two buffer overflows in src/backend/utils/adt/oracle_compat.c. 1) lpad(text, integer, text) function 2) rpad(text, integer, text) function --[ Details: The code for this functions is src/backend/utils/adt/oracle_compat.c::lpad() and src/backend/utils/adt/oracle_compat.c::rpad() respectively. The code suffers from a buffer overflow (of course). --[ How to reproduce: shell> pgsql template1 postgres template1=# select version(); version -----------------------------------------------------------PostgreSQL 7.2 on i686-pc-linux-gnu, compiled by GCC 2.96 (1 row) template1=# create database my_db with encoding='UNICODE'; CREATE DATABASE template1# \c my_db You are now connected to database my_db. my_db=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy'); 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. !# The same for rpad() function. The vulnerable encodings are: EUC_JP, EUC_CN, EUC_KR, EUC_TW, UNICODE, MULE_INTERNAL. --[ Solution Secure coding of web applications, input validation checks...etc... ________________________________________________________________________ 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
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
From
Tom Lane
Date:
Vince Vielhaber <vev@michvhf.com> writes:
> And another one. Sure would be nice if shit-for-brains would mention
> it to us first.
I don't even mind the "first" part, but it would certainly be polite of
him to cc: pghackers rather than expecting us to dig it off bugtraq.
But, as someone else pointed out, he's not doing this for our benefit,
it's to make himself look good. The only audience he cares about is
bugtraq, I suspect.
regards, tom lane
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
From
Neil Conway
Date:
Vince Vielhaber <vev@michvhf.com> writes:
> And another one.
This patch should fix the problem. Doesn't include my previous patch
for repeat(). Again, somewhat off-the-cuff, so I might have missed
something...
test=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
ERROR: Requested length too large
test=# select rpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
ERROR: Requested length too large
(That's on a Unicode DB, haven't tested other encodings but AFAICT
this fix should still work.)
Cheers,
Neil
--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
Attachment
On 20 Aug 2002, Neil Conway wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
> > And another one.
>
> This patch should fix the problem. Doesn't include my previous patch
> for repeat(). Again, somewhat off-the-cuff, so I might have missed
> something...
>
> test=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
> ERROR: Requested length too large
> test=# select rpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
> ERROR: Requested length too large
>
> (That's on a Unicode DB, haven't tested other encodings but AFAICT
> this fix should still work.)
Is there any chance that pg_database_encoding_max_length() could return
zero and give a divide by zero error? Or is that trapped?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo
atPop4 Networking http://www.camping-usa.com http://www.cloudninegifts.com http://www.meanstreamradio.com
http://www.unknown-artists.com
==========================================================================
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)
From
Neil Conway
Date:
Vince Vielhaber <vev@michvhf.com> writes: > On 20 Aug 2002, Neil Conway wrote: > Is there any chance that pg_database_encoding_max_length() could return > zero and give a divide by zero error? Or is that trapped? I don't think so (the array of encodings that contains the data seems to be pre-defined), but I know next to nothing about multibyte, so I may be wrong. In any case, the "divide by zero" error would cause an elog(ERROR) anyway, not a segfault... Cheers, Neil -- Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
> > (That's on a Unicode DB, haven't tested other encodings but AFAICT > > this fix should still work.) > > Is there any chance that pg_database_encoding_max_length() could return > zero That's impossible or at least is the evidence of something badly broken. > and give a divide by zero error? Or is that trapped? -- Tatsuo Ishii
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: > Vince Vielhaber <vev@michvhf.com> writes: > > And another one. > > This patch should fix the problem. Doesn't include my previous patch > for repeat(). Again, somewhat off-the-cuff, so I might have missed > something... > > test=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy'); > ERROR: Requested length too large > test=# select rpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy'); > ERROR: Requested length too large > > (That's on a Unicode DB, haven't tested other encodings but AFAICT > this fix should still work.) > > Cheers, > > Neil > > -- > Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Patch applied. Thanks.
---------------------------------------------------------------------------
Neil Conway wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
> > And another one.
>
> This patch should fix the problem. Doesn't include my previous patch
> for repeat(). Again, somewhat off-the-cuff, so I might have missed
> something...
>
> test=# select lpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
> ERROR: Requested length too large
> test=# select rpad('xxxxx',1431655765,'yyyyyyyyyyyyyyyy');
> ERROR: Requested length too large
>
> (That's on a Unicode DB, haven't tested other encodings but AFAICT
> this fix should still work.)
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073