Retransmitted (I haven't received any acknowledge except "this has been submitted to the moderator), so I assume it's been lost with your mailbox crash. ----- Forwarded message from Pierre Beyssac <pb> ----- Date: Thu, 30 Jul 1998 19:14:47 +0200 From: Pierre Beyssac <pb> To: "John D. Hardin" <jhardinat_private>, BUGTRAQat_private Subject: Re: A way to prevent buffer overflow exploits? (was: "Any user can panic OpenBSD machine" flamefest) X-Mailer: Mutt 0.92.8i On Wed, Jul 29, 1998 at 09:13:26AM -0700, John D. Hardin wrote: > parameters and return addresses. 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? Note that it would only prevent exploits executing foreign code on the stack (granted, it's about 99% of the current buffer overflow exploits). But it wouldn't prevent "data" attacks which use the buffer overflow to change another variable value (the sendmail -d exploit is one such example). > Or how about allocating space for all local variables from the system heap > automatically and transparently rather than placing them on the stack? This wouldn't be easy to implement when using functions such as setjmp() / longjmp() which manipulate the stack pointer. Probably doable, though, by garbage collecting from time to time. Funnily enough, this is almost the exact reverse from alloca() :-) > Or how about automatically allocating space just for local strings? This > would take care of buffer overflows with minimal impact, wouldn't it? > > Granted, fixing the applications is the better long-term solution, but > these might be ways to buy time to do the auditing and correction. Probably the whole C string functions should be reconsidered, for a start. strncpy() and friends are a first step, but they still have a problem in that they fail to guarantee that the last byte of the buffer will always be '\0'. This causes yet another series of programmer errors forgetting to put it themselves afterwards. Maybe we'll see exploits for this one day... Also, just truncating a long string is admittedly better than crashing the program, but it has its problems too because you can lose important data (the sendmail HELO bug, which allowed you to hide the source IP address in the Received: lines). Exiting in error (possibly logging the fault) might be a better idea. Or maybe better, use the GNU philosophy: there should be as few arbitrary limits as possible on buffer sizes (which then can cause DoS attacks by memory exhaustion...). But to stay on the subject of how to protect vulnerable code without rewriting it, IMHO StackGuard or making the stack non-executable fit the bill rather nicely, even though they are not perfect. -- Pierre.Beyssacat_private ----- End forwarded message ----- -- Pierre.Beyssacat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:11:12 PDT