Обсуждение: @(#)Mordred Labs advisory 0x0004: Multiple buffer overflows in PostgreSQL. (fwd)

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

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

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

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

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