Re: [inbox] Re: RE: Linux (in)security

[Valdis.Kletnieks () vt edu]

On Sun, 26 Oct 2003 11:55:15 PST, "Gregory A. Gilliss" said:

> experts. Mudge and Aleph1 found buffer overflows BITD. Route discovered

Were Mudge and Aleph1 already doing that stuff when the Morris Worm went out in
late 1988 and abused some buffers in fingerd?  "Smashing the stack for fun and
profit" was first (to my knowledge) in Phrack 49, and hit Bugtraq Sep 9. 1996,
almost 8 years later.

> SYN flooding. No idea who claims credit for the first race condition - 
> any takers? Point is, software comes out of the box and gets reviewed

The IBM Systems/360 had several models (at least the 65, 67, 75, and 95, I
suspect that the 20, 30, 40, 44, and 50 weren't pipelined enough to have the
problem) that supported "imprecise interrupts".  To summarize the problem, it
was possible for a write to memory to take several instruction cycles to
actually be reported.  As a result, it was possible to make a bad store to
memory, then issue an SVC (supervisor call) instruction, and be in priviledged
mode before the interrupt came back.  The supervisor code would then get a
totally unexpected program exception interrrupt and roll over and die.  The model
95 drew on the experience of the earlier models and forced a pipeline drain before
executing SVC.

Also, Karger and Schell, in their classic "Multics Security Evaluation" paper,
mentioned finding a *flaw* in the way that argument lists were copied to system
space to prevent another processor from accessing them before they were done
being validated. So obviously the Multics crew understood TOC/TOU issues
enough to guard against them (even if not perfectly).

So in both cases, people were aware of the concept of race conditions at least
as early as the late 60s - in other words, very soon after multiprogramming and
timesharing made security an issue at all.

Attachment: _bin
Description: