Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in - Mailing list pgsql-hackers

From Dann Corbit
Subject Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Date
Msg-id D90A5A6C612A39408103E6ECDD77B82920D14E@voyager.corporate.connx.com
Whole thread Raw
List pgsql-hackers
> -----Original Message-----
> From: Mark Pritchard [mailto:mark@tangent.net.au]
> Sent: Monday, August 19, 2002 11:27 PM
> To: Dann Corbit; Neil Conway
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] @(#) Mordred Labs advisory 0x0001:
> Buffer overflow in
>
>
> On Tue, 20 Aug 2002 15:35, Dann Corbit wrote:
> > Most computer virus problems are caused by buffer overrun.  Someone
> > decided it wasn't very important.
> >
> > Some computer viruses have caused billions of dollars in damage.
> > Sounds important to me.
> >
> > "Please try our database.  Someday, we hope to close off
> all the virus
> > entry points, but right now, we figure it isn't too important."
>
> This sounds a little hysterical to me...don't happen to have
> a remotely
> accessible database do you? :)

I tend to be hyperbolic at times.
> > Will you trust your multi-million dollar database to
> someone who says
> > the above?  I think the priorities are upside down.  Any *known*
> > buffer-overrun _must_ be repaired, and as quickly as possible.  And
>
> As always, feedback accepted in diff -c format.
>
> Seriously though, Oracle was unbreakable for what, two days?
> Software has
> bugs. I'm sure there are a stack more in PostgreSQL.
>
> You limit your exposure to bugs/defects/etc through the use
> of multiple layers
> of protection. If you leave your database out in the wild,
> you deserve to be
> hacked.

Nobody deserves to be hacked.  Security should assume that each link in
the chain is the only way to bar the door.  IMO-YMMV.

> > potential overruns should be identified.  A grep for
> memcpy, strcpy,
> > gets, etc. should hunt down most of them.  A known buffer overrun
> > should fill the designer of a product with abject terror.  And I
> > really mean that, literally.  If you *know* of a buffer
> overrun, and
> > simply decide
>
> I'd be worried if my IT consultants experienced "abject
> terror". I much prefer
> them to be calm, safe in the knowledge that vulnerabilities
> such as this will
> not cause me any problems, because they had the forethought
> to plan for
> situations like this and limit their exposure.

My comment was meant to emphasize urgency, rather than irrational
behavior.  Somewhat hyperbolic, obviously.
> I worry about two pieces of software - Apache and OpenSSH. I
> compile from
> source, knowing that I can fix the issue (be it the recent
> issues with either
> piece of software) as soon as the fixed source becomes
> available. I may be in
> the minority, but at least I don't experience abject terror
> too often (well,
> unless I let my sister drive my car...but that is another story).
>
> Cheers
>
> Mark
>


pgsql-hackers by date:

Previous
From: Mark Pritchard
Date:
Subject: Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in
Next
From: John Gray
Date:
Subject: Build failure in current CVS (src/backend/utils/mb/conversion_procs)