[7511] in bugtraq
[pb: Re: A way to prevent buffer overflow exploits? (was: "Any
daemon@ATHENA.MIT.EDU (Pierre Beyssac)
Tue Aug 4 12:10:55 1998
Date: Tue, 4 Aug 1998 10:40:00 +0200
Reply-To: Pierre Beyssac <Pierre.Beyssac@HSC.FR>
From: Pierre Beyssac <Pierre.Beyssac@HSC.FR>
To: BUGTRAQ@NETSPACE.ORG
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" <jhardin@wolfenet.com>, BUGTRAQ@NETSPACE.ORG
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.Beyssac@hsc.fr
----- End forwarded message -----
--
Pierre.Beyssac@hsc.fr
