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:
pgp00123.pgp
Description: PGP signature