Managed Code and Runtime Environments - Another layer of added security?

[smb at cs.columbia.edu (Steven M. Bellovin)]

On Wed, 29 Mar 2006 14:50:39 -0500, Olin Sibert <u3902 at siliconkeep.com>
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