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)
[email protected]
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
