Re: Public disclosure of discovered vulnerabilities

David Wagner wrote:

> Nick Maclaren wrote:
>
>>>>"David Wagner" <daw@taverner.cs.berkeley.edu> wrote:
>>>>
>>>>>heap exploits,
>>>>>return-into-libc buffer overruns, GOT table overruns, NOP
>>>>>landing pads, [...]
>>>>>format string vulnerabilities, integer overflow
>>>>>vulnerabilities, double-free vulnerabilities, [...]
>>
>>Er, no. I was familiar with all of those more than 30 years ago,
>>and have had colleagues that were 20 years before that!
>
>
> Do you have any documentation of this?
>
> Please forgive me for being so skeptical. I really don't mean to
> distrust you. I'm just trying to figure out how it is that you and
> Hadstate both knew the intricacies of how to exploit a double-free bug
> more than 30 years ago -- but no one in the security community did.
> Even the graybeards in the security community (the ones that I know)
> were surprised by many of these discoveries, I thought.
>
Buffer overflow problems are a very natural occurrence. If noise on the
link corrupts either the length field or the end of frame flag then you
get a buffer overflow. This means that building buffer overflow
protection into receivers was almost certainly routine by the late 1940s
or early 1950s.

Some where along the line the beginner's mistake of leaving out the
overflow protection/recovery was allowed to go unchecked. What is new
are malicious overflows that exploit this beginner's mistake by both
introducing and running enemy supplied code.

The underlying message handling system should have detected the receive
buffer overflow and recovered by discarding additional data until the
start of the next message and discarded the content of the buffer.

Andrew Swallow
Received on Thu Sep 29 21:41:12 2005