Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in

Vince Vielhaber <vev@michvhf.com>

From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Date: 2002-08-20T20:11:26Z
Lists: pgsql-hackers
On Tue, 20 Aug 2002, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> 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.

Where do we check that this:

		result = (text *) palloc(tlen);

is even successful?  Is it in one of the macros (VARATT_SIZEP or VARDATA)?
It appears like it goes into the count and copy regardless.

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