On Wed, 29 Mar 2006 14:50:39 -0500, Olin Sibert <[EMAIL PROTECTED]> wrote:
> While we're on Multics lessons, let's not forget upward-growing > stacks (which were a natural consequence of the segmented > addressing architecture). > > Multics code was not immune to buffer overflows, but in most cases > the effect was blunted because the out-of-range index values could > only affect data beyond the current activation record--in contrast > with most linear addressing systems where an overflow is almost > always able to reach important values like the return address. > I've heard that claim before; I've always thought it overrated. In an upward-growing stack, if you overflow a parameter passed to a subroutine it will overwrite the subroutine's return address. Since many buffer overflows happen as a result of library calls -- think strcpy() or scanf() -- this can be *more* of a danger. The real advantage on Multics was PL/I, where character strings of declared lengths were a built-in data type. I'm teaching Operating Systems this semester; the textbook I'm using constantly mentions the similarities of the Pentium hardware architecture to Multics, complete with segments and rings. (I've also told my students to read Organick's book, because I can't bear the thought of a CS major knowing nothing of Multics....) When was the last time you did an inter-ring call on a Pentium? The real issue, even on Multics, wasn't the hardware features, it was the lack of applications that were designed in a way that made them useful. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php