> Don't hold your breath; Contrary to kernel-based solutions (mainly
> Solar's Linux Kernel Patch from Openwall Project -
> http://www.openwall.com/linux/ ), this one deals only with some
> specific functions (e.g. strcpy) so it is not a general solution
> against buffer-overflows.
In fact, it is even less general than the stack smashing portions
of Solar Designer's Linux patches.
> Before you argue, let me say that by writing "general" I didn't mean
> that the kernel-based solutions *solve* the problem; You still can
> garbage the stack, but you can't execute it, so in the worst case,
> the victim process will fail, but no *real* damage will be caused to
> the system. What I meant was that it doesn't protect only specific
> functions, but ANY function.
As was pointed here by Guy Cohen, there are ways to defeat the
kernel level protections.
To summarize, libsafe is as much a workaround as is Solar Designer's
patch.
Furthermore, its heuristics may prevent overwriting a function's stack
frame, but they don't prevent overwriting sensitive data in local
variables using a buffer overflow. (Similar techniques were used to
exploit Sendmail a long time ago, only using global variables.)
> Linus and Alan Cox claim that preventing the stack from being
> executed is not a real solution but only a workaround, so they don't
> agree to insert it into the standard kernel. This is also why most of
> the distributions (I think except for Mandrake in its highest
> security level and Definite-Linux, as well as some security-focused
> distros) don't include the kernel-based solutions, but plan to
> include Lucent's solution.
I think that this simply reflects their lack of technical sense,
compared to Linux et. al. They are simply going for the most
simple and unintrusive band aid.
=================================================================
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]
