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

From: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Date: 2002-08-21 02:15:51
Message-ID: Pine.LNX.4.21.0208211202280.30925-100000@linuxworld.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 21 Aug 2002, Christopher Kings-Lynne wrote:

> > Should someone from the core team perhaps get in contact with this guy
> > and ask if he could get in contact with the development team before
> > publicizing any further security holes? AFAIK that is standard
> > operating procedure in most cases...
> >
> > Second, it might be worth pushing a 7.2.2 release containing the fix
> > for this bug, as well as the datetime problem. If that sounds
> > reasonable to the people who have to do the most work on a new release
> > (e.g. Marc), I can volunteer to backport a fix for the datetime
> > problem.
>
> It'd be better to contact the dude and get all his bugs out of him, fix them
> all and issue a 7.2.2 with all the fixes.

That wouldn't work because it seems he is making advisories at the
time he discovers a bug/flaw. That is, he is not directly interested in
the robustness of Postgres -- rather, another poster put it, his
reputation on bugtraq. That's fine but it doesn't mesh well with the
co-ordinated effort you describe.

I still do not see this as being a serious security problem unless you are
providing access to postgres to untrusted users. The advisory's
recommendation of killing the postmaster as a solution to these bugs is
akin to saying 'kill ssh if there's a libc bug'. If you are providing
access to untrusted users, that advice is worthwhile. But if your users
are trusted and could produce the same effect in any other number of
reasons, the advice is useless.

As for making a 7.2.2 release for the sake of form and for those users who
do provide access to untrusted users (universities, ISPs, say) this would
be pointless without the changes to opaque which Tom has put forward and
may/may not work on before 7.3 beta. I'm not sure that the core guys would
be too happy doing that *and* requiring an initdb for a minor release (as
I presume Tom's changes will require one).

Gavin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-08-21 03:10:54 Re: Build failure in current CVS (src/backend/utils/mb/conversion_procs)
Previous Message Christopher Kings-Lynne 2002-08-21 01:49:57 Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in PostgreSQL (fwd)