This is a multi-part message in MIME format. --------------FC71E981BF5DCA23B37F71BF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Re-post of my own message lost on the Bugtraq server: John D. Hardin wrote: > 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 :) More specifically, the 360/370/390 architecture writes the return address into the code space just ahead of the function entry point. Poof: no stack :-), and no recursion :-( > (to continue the topic drift, and throw some ideas into the pot...) > > I wonder how feasible it would be to modify GCC to generate code with two > stacks (or something equivalent): one for local variables, the other for > parameters and return addresses. We considered this approach when we were designing StackGuard ( http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ ) but rejected it for the following reasons: * requires much more intrusive changes to the compiler than StackGuard does * breaks compatibility with existing libraries Other than that, yeah it'll work. On the other hand, StackGuard already exists. StackGuard works by doing integrity checks on the stack each time a function returns: stack smashes are not prevented, but they are detected before the program jumps to the attacker's code, preventing the exploit from completing. StackGuard is compatible with existing libraries (i.e. a StackGuard-protected program can link with an ordinary library) and pretty much stomps stack smashing vulnerabilities in vulnerable code. In addition, if someone tries to perpetrate a stack smash, you get an intruder alert in your syslog. > Might moving the local variables away > from the return addresses this way be a relatively cheap way to prevent > buffer overflow exploits without having to recode all of the applications > or using expensive bounds-checking? The performance penalties of StackGuard are nominal. We could not measure any significant performance penalty in a StackGuard-protected Apache web server when we benchmarked it with WebStone. > Or how about allocating space for all local variables from the system heap > automatically and transparently rather than placing them on the stack? I agree with Glass: heaps are slow. Consider the difference between the SML and CAML implementations of the ML language. SML uses every compiler optimization hack in the book, and passes arguments on the heap. CAML uses trivial optimizations, passes its arguments on the stack, and frequently beats SML in performance. > Or how about automatically allocating space just for local strings? This > would take care of buffer overflows with minimal impact, wouldn't it? That would break the C standard, which states that local variables are allocated in consecutive memory, with optional padding between them. > Granted, fixing the applications is the better long-term solution, but > these might be ways to buy time to do the auditing and correction. Absolutely. StackGuard's intruder alert also tells you which function got smashed, so you can go fix it, or if you don't have the source, e-mail the report to the code maintainer. Crispin ----- Crispin Cowan, Research Assistant Professor of Computer Science, OGI StackGuard: protect your software against Stack Smashing Attack http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Support Justice: Boycott Windows 98 --------------FC71E981BF5DCA23B37F71BF Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <35C0B28F.72F11952at_private> Date: Thu, 30 Jul 1998 10:51:11 -0700 From: Crispin Cowan <crispinat_private> Organization: Oregon Graduate Institute X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: "John D. Hardin" <jhardinat_private> CC: BUGTRAQat_private Subject: Re: A way to prevent buffer overflow exploits? (was: "Any user can panic OpenBSD machine" flamefest) References: <Pine.LNX.3.96.980729085541.23601D-100000at_private> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John D. Hardin wrote: > 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 :) More specifically, the 360/370/390 architecture writes the return address into the code space just ahead of the function entry point. Poof: no stack :-), and no recursion :-( > (to continue the topic drift, and throw some ideas into the pot...) > > I wonder how feasible it would be to modify GCC to generate code with two > stacks (or something equivalent): one for local variables, the other for > parameters and return addresses. We considered this approach when we were designing StackGuard ( http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ ) but rejected it for the following reasons: * requires much more intrusive changes to the compiler than StackGuard does * breaks compatibility with existing libraries Other than that, yeah it'll work. On the other hand, StackGuard already exists. StackGuard works by doing integrity checks on the stack each time a function returns: stack smashes are not prevented, but they are detected before the program jumps to the attacker's code, preventing the exploit from completing. StackGuard is compatible with existing libraries (i.e. a StackGuard-protected program can link with an ordinary library) and pretty much stomps stack smashing vulnerabilities in vulnerable code. In addition, if someone tries to perpetrate a stack smash, you get an intruder alert in your syslog. > Might moving the local variables away > from the return addresses this way be a relatively cheap way to prevent > buffer overflow exploits without having to recode all of the applications > or using expensive bounds-checking? The performance penalties of StackGuard are nominal. We could not measure any significant performance penalty in a StackGuard-protected Apache web server when we benchmarked it with WebStone. > Or how about allocating space for all local variables from the system heap > automatically and transparently rather than placing them on the stack? I agree with Glass: heaps are slow. Consider the difference between the SML and CAML implementations of the ML language. SML uses every compiler optimization hack in the book, and passes arguments on the heap. CAML uses trivial optimizations, passes its arguments on the stack, and frequently beats SML in performance. > Or how about automatically allocating space just for local strings? This > would take care of buffer overflows with minimal impact, wouldn't it? That would break the C standard, which states that local variables are allocated in consecutive memory, with optional padding between them. > Granted, fixing the applications is the better long-term solution, but > these might be ways to buy time to do the auditing and correction. Absolutely. StackGuard's intruder alert also tells you which function got smashed, so you can go fix it, or if you don't have the source, e-mail the report to the code maintainer. Crispin ----- Crispin Cowan, Research Assistant Professor of Computer Science, OGI StackGuard: protect your software against Stack Smashing Attack http://www.cse.ogi.edu/DISC/projects/immunix/StackGuard/ Support Justice: Boycott Windows 98 --------------FC71E981BF5DCA23B37F71BF--
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:19 PDT