resend

[smb () RESEARCH ATT COM (Steve Bellovin)]

I didn't see this appear, and the thread shows no signs of dying out....

------- Forwarded Message

To: Peter Jeremy <peter.jeremy () AUSS2 ALCATEL COM AU>
cc: BUGTRAQ () netspace org
Subject: Re: A way to prevent buffer overflow exploits?
Date: Thu, 30 Jul 1998 14:45:51 -0400
From: Steve Bellovin <smb () postal research att com>

In message <98Jul30.074943est.40326 () border alcanet com au>, Peter Jeremy writes
:
> On Thu, 30 Jul 1998 02:13:26 +1000, "John D. Hardin" <jhardin () WOLFENET COM> w
> rote:
> > On Tue, 28 Jul 1998, Cy Schubert wrote:
> >
> > > What makes MVS (and VM) so impervious to attack is that the S/390
> > > hardware doesn't rely on a stack, making effective buffer overruns
> > > considerably more difficult.  (A little off topic :)
> Re-entrant and recursive functions are also considerably more
> difficult :-(.  (And the return address will still wind up in memory
> unless you're calling a leaf routine).

It's time for me to disclose a dark secret -- lo these many years ago,
I was a systems programmer on OS/360 MVT, the ancestor of MVS.  And
yes, OS had re-entrant programs 30 years ago, on a non-stack machine.

By convention, before calling a subroutine it was necessary to have
register 13 pointing to a save area.  The called routine saved
registers in this block, including register 14, the return address.  It
could then do a system call that would allocate a new block of storage;
this block was used for local variables and for the save area to be
passed to any routines it called.

Inefficient?  Sure, though routines that behaved in precisely that
fashion were moderately rare; most programs used static storage areas
for their own save areas.  PL/I -- the only stack-oriented language
that was really important in those days on that platform -- did its own
storage management; as I recall, at least one PL/I compiler used
register 12 as a stack pointer, to avoid the system call overhead.

No one worried much about stack-smashing in those days.  It would have
been a difficult attack, though, since the stack grew up, and local
variables would have been allocated after the save area.  (While the
current routine's save area didn't have the actual return address, by
convention it had a back-pointer to the previous save area at a fixed
offset from the start of the area.  The attack would have involved
creating a bogus save area with register 14 pointing to the new code,
then smashing the back pointer in the current save area.)

------- End of Forwarded Message