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]
