I didn't see this appear, and the thread shows no signs of dying out.... ------- Forwarded Message To: Peter Jeremy <peter.jeremyat_private> cc: BUGTRAQat_private Subject: Re: A way to prevent buffer overflow exploits? Date: Thu, 30 Jul 1998 14:45:51 -0400 From: Steve Bellovin <smbat_private> In message <98Jul30.074943est.40326at_private>, Peter Jeremy writes : > On Thu, 30 Jul 1998 02:13:26 +1000, "John D. Hardin" <jhardinat_private> 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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:38 PDT