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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vince Vielhaber <vev(at)michvhf(dot)com>
Cc: Justin Clift <justin(at)postgresql(dot)org>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date: 2002-08-20 13:39:58
Message-ID: 5272.1029850798@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vince Vielhaber <vev(at)michvhf(dot)com> writes:
> On Mon, 19 Aug 2002, Tom Lane wrote:
>> I'd like to see something done about this fairly soon, but it's not
>> happening for 7.3 ...

> Can we trap and just return an error before it goes into the weeds and
> put the subdividing opaque fix in later?

I don't think there's any quick and dirty solution.

One thing we could probably do in a relatively short amount of time,
considering that we already have one pseudo-type in the system, is to
go ahead and invent the "C string" pseudo-type and then change all the
built-in I/O functions to be declared as taking or returning C string
(as appropriate). We couldn't really do strong type checking on this
yet, because we couldn't expect user-defined types' I/O functions to be
declared correctly for awhile yet, but at least it would plug the hole
for built-in types.

What this needs is someone to do the legwork...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Copeland 2002-08-20 13:48:00 Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Previous Message ngpg 2002-08-20 13:08:26 Re: [SECURITY] DoS attack on backend possible