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