Re: 2nd Linux kernel patch to remove stack exec

[solar () SUN1 IDEAL RU (Solar Designer)]

Hello!

> 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,
others can't.

> 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
working patch?

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
subject already.

Signed,
Solar Designer