> Here is where the real argument lives.
> You are claiming that the patch adds no real security. You clame it does
> nothing more then moving to a non-popular arch would do.
> I disagree. The patch actually makes creating this type of attack much
> harder, and in some cases impossible.
"Much harder" how? Instead of returning to some doctored code on the stack,
you just return to the start of system(3) or some such. Sure, different
technique, perhaps needs to be tuned and adjusted according to the target
program and its version and a few more parameters. Impossible? Well,
perhaps against statically linked programs that don't contain such stuff,
but as long as you have a shared libc you are vulnerable AFAIKS. And you
could fake a trampoline on the stack too...
And note that the latest round of attacks against Solaris bind (I never run
stock distribution servers as a policy matter, they usually lag _way_
behind in security) gave me a _huge_ /var/adm/messages, full of messages
from bind that was being bombarded with many thousands of weird requests.
Installing nonexecutable stack would have given me a whole bunch of nice
core files, and a nameserver that did not work for more than a couple of
seconds at a time. That isn't exactly "security" in my book.
> The effectiveness of this patch comes from two places:
> A) It's rare and breaks all existing attacks.
> B) I actually makes that class of attack harder to accomplish.
> Just because A will go away if this patch were everywhere, you still
> derrive additional security from B.
A bit of extra security, at the cost of adding cruft to the kernel each
time a new trampoline code layout comes around, some performance hit for
everybody and DoSes all over the place instead of getting the broken
programs fixed? No, thanks.
If you want to install it, go right ahead: this is free software in a free
world. It might help you some for some time, but does _not_ help everybody,
at least not in the long run.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/