@(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

Started by Vince Vielhaberover 23 years ago8 messages
#1Vince Vielhaber
vev@michvhf.com

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 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 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

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Vince Vielhaber (#1)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

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

#3Neil Conway
neilc@samurai.com
In reply to: Vince Vielhaber (#1)
1 attachment(s)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

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

Attachments:

pad_fixes-1.patchtext/x-patchDownload
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 -0000	1.38
--- src/backend/utils/adt/oracle_compat.c	20 Aug 2002 21:04:07 -0000
***************
*** 199,204 ****
--- 199,209 ----
  
  #ifdef MULTIBYTE
  	bytelen = pg_database_encoding_max_length() * len;
+ 
+ 	/* check for integer overflow */
+ 	if (len != 0 && bytelen / pg_database_encoding_max_length() != len)
+ 		elog(ERROR, "Requested length too large");
+ 
  	ret = (text *) palloc(VARHDRSZ + bytelen);
  #else
  	ret = (text *) palloc(VARHDRSZ + len);
***************
*** 310,315 ****
--- 315,325 ----
  
  #ifdef MULTIBYTE
  	bytelen = pg_database_encoding_max_length() * len;
+ 
+ 	/* Check for integer overflow */
+ 	if (len != 0 && bytelen / pg_database_encoding_max_length() != len)
+ 		elog(ERROR, "Requested length too large");
+ 
  	ret = (text *) palloc(VARHDRSZ + bytelen);
  #else
  	ret = (text *) palloc(VARHDRSZ + len);
#4Vince Vielhaber
vev@michvhf.com
In reply to: Neil Conway (#3)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer

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 at Pop4 Networking
http://www.camping-usa.com http://www.cloudninegifts.com
http://www.meanstreamradio.com http://www.unknown-artists.com
==========================================================================

#5Neil Conway
neilc@samurai.com
In reply to: Vince Vielhaber (#4)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

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

#6Tatsuo Ishii
t-ishii@sra.co.jp
In reply to: Vince Vielhaber (#4)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer

(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

#7Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Neil Conway (#3)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows

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, Pennsylvania 19073
#8Bruce Momjian
pgman@candle.pha.pa.us
In reply to: Neil Conway (#3)
Re: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows

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, Pennsylvania 19073