Of course, the best way to avoid buffer overflows is to use good
libraries, or even better a good language. Neither Python nor Perl nor
Guile nor Tcl will *let* you have a buffer overflow as long as the
implementation is bug free. Since you are relying anyway on external
code (e.g., libc), might as well use a language where this is the only
possible source for buffer overflows. If you must code in C, at least
use the safe routines in glib (for example g_strdup_sprintf) rather then
using unsafe functions such as sprintf.

being-careful-is-easier-when-not-leaving-on-the-edge-ly y'rs, Z.

On Wed, 26 Apr 2000, Yosi wrote:

> Buffer ovrflow is one of the most common security bugs in software.
> Hoever, imho, relying on such tools as Lucent's library is not a good
> methodology. A programmer must be security-oriented when writing code. In 
> the "Secure-Programming HOWTO", it says that "Paranoia is a virtue". That 
> is, the programmer's role is more than just compile his code with a library 
> that is supposed to defend his code from buffer overflows. He must audit his 
> code for potential hazards, and write the code in such a way, that buffer 
> overflows and other security
> issues won't happen in the first place. Lucent's library is a welcome
> addition to a set of tools that already exists in the Linux world 
> (StackGuard and StackShield are just two examples). However, they
> must not be relied on to provide total security.
> 
> Yosi
> 
> P.S
> Speaking of StackGuard, here is a recent post I found on BugTraq that
> compares Lucent's library to StackGuard:
> 
> JEFF PFOHL wrote:
> 
> >Does anyone know anything about this?
> >
> >  http://www.bell-labs.com/org/11356/html/security.html
> 
> Solar Designer has posted his analysis to the Linux security-audit
> mailing list
>    http://www2.merton.ox.ac.uk/~security/security-audit-200004/0069.html
> 
> Perry Wagle (principle StackGuard developer, cc'd) has written an
> analysis comparing StackGuard to libsafe (attached).  The summary is
> as follows:
> 
>       * Use StackGuard where you can, because it is safer:
>       o Libsafe only wraps selected string library functions.  Buffer
>         overflows affecting other library functions or user-written
>         loops will not be protected
>       o Libsafe attempts to wrap these functions by parsing the
>         stack, but it doesn't always succeed.  In particular, libsafe
>         depends on the existance of the frame pointer, and fails when
>         it isn't present, as happens if the code was compiled with
>         -fno_fp, or if the optimizer removed the frame pointer.
> 
>       * Use Libsafe where you cannot use StackGuard, i.e. for
>         binary-only applications.
> 
> My further comment on libsafe:  the paper that the authors will be
> presenting at USENIX in June presents two forms of defense ("library
> intercept" and binary-rewrite (BRW)) and only the library intercept
> appears to be embodied in the publicly available libsafe, which is
> why libsafe only protects against overflows that use particular
> string library functions.
> 
> The BRW method is a pseudo-compiler that can transform binaries into
> "safe" programs by transforming the binary.  It copies program onto
> the heap, inserting checks as it goes.  The copy-to-the-heap is to
> make space for the additional checks.  I really like the BRW method,
> and hope it becomes available.
> 
> If my understanding is mistaken, and BRW is actually in the
> distributed libsafe, please correct me.
> 
> Crispin
> -----
> Crispin Cowan, CTO, WireX Communications, Inc.    http://wirex.com
> Free Hardened Linux Distribution:                 http://immunix.org
>                    JOBS!  http://immunix.org/jobs.html
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 
> 
> =================================================================
> To unsubscribe, send mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
> 
> 

--
Moshe Zadka <[EMAIL PROTECTED]>. 
http://www.oreilly.com/news/prescod_0300.html
http://www.linux.org.il -- we put the penguin in .com


=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to