mailing list archives
Re: 2nd Linux kernel patch to remove stack exec
From: solar () SUN1 IDEAL RU (Solar Designer)
Date: Mon, 14 Apr 1997 15:47:54 -0300
Perhaps some people don't understand, every single Linux binary on
every platform supported that I know of, needs an executable stack to
have signals work at all. When you type 'ls' a signal can get
It is not the binaries that need executable stack, but the current signal
handling implementation in the kernel. There's a significant difference.
delivered to your shell to notify it that the child has exited. Just
about every program needs signals that is of any use.
Do you really believe I'm running for 3 days now without any signals
being generated? If you read my comments to the patch, or looked through
the patch itself (no offence), you would notice that there's a fix for
this problem in there. What I do is temporary enable the stack execution
permission, for the signal handler execution period. Of course, this leaves
possible buffer overflows in signal handlers exploitable, but I don't care
much about that since most of the code is still executed with the protection
enabled. There's also a better solution (someone already mentioned it here):
make the kernel call signal handlers with an invalid return address (NULL
for example) on the stack, so the control will get to a kernel's exception
(page fault for example) handler, which will check for that condition.
If you make this change to take away execute permission on the users
stack, all existing Linux binaries would break.
Well, again, I'm running this patched kernel right now, while typing this
message, and I have X running, a SSH client to connect to the machine I'm
typing this message on, an IRC client, a password cracker, ... Everything
works fine for three days already. Only most overflow exploits (well, except
for one of them, SuperProbe, I explained why already) stopped working. Some
of them can be re-coded a more complicated way, to make them work again,
then, it would take a lot of effort and time to get from that point to
it actually going into the kernel.
I'm not sure if it should go to the kernel distribution. But a working patch
(or a configurable kernel feature) seems to me like a good idea, so those who
like that stuff, can use it, and others have no reason to complain.
Let this thread die a painless quick death...
It won't unless there's a working patch. It is not the first time such a
discussion starts. I looked through linux-kernel archives from a year ago,
there was a similar discussion then, but it ended at the trampoline stuff.
Now that trampolines are no longer a problem (I explain that in my message
when posting the 2nd patch), why not bring that discussion to an end -- a
I've made some minor (quite important though) changes since the last patch
I posted (2nd), but am not going to re-post right now, just in case some
problems are reported, so the patch I'll post will most likely be final, and
I don't flood with different versions. I'll explain what the patch prevents
from (definitely not all buffer overflows, there're still some exploitable),
and the possible problems in the same message also, as a summary of the
discussion. I admit that there have been too many messages posted on this