Re: @(#) 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? :)

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

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

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