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

From: "Dann Corbit" <DCorbit(at)connx(dot)com>
To: "Mark Pritchard" <mark(at)tangent(dot)net(dot)au>, "Neil Conway" <neilc(at)samurai(dot)com>
Cc: "Justin Clift" <justin(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 06:34:56
Message-ID: D90A5A6C612A39408103E6ECDD77B82920D14E@voyager.corporate.connx.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Mark Pritchard [mailto:mark(at)tangent(dot)net(dot)au]
> Sent: Monday, August 19, 2002 11:27 PM
> To: Dann Corbit; Neil Conway
> Cc: Justin Clift; Tom Lane; Christopher Kings-Lynne;
> pgsql-hackers(at)postgresql(dot)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
>

Browse pgsql-hackers by date

  From Date Subject
Next Message John Gray 2002-08-20 11:06:58 Build failure in current CVS (src/backend/utils/mb/conversion_procs)
Previous Message Mark Pritchard 2002-08-20 06:26:57 Re: @(#) Mordred Labs advisory 0x0001: Buffer overflow in