Re: Unexecutable stack

Khimenko Victor (khim@sch57.msk.ru)
Tue, 28 Dec 1999 16:47:41 +0300 (MSK)


In <Pine.LNX.4.10.9912280816280.24316-100000@futurism.arcticnet.net> Gregory Maxwell (greg@linuxpower.cx) wrote:
> On Mon, 27 Dec 1999, Zachary Amsden wrote:

>> Just for reference, here are the facts:
>>
>> 1) Not all architectures support this

> True. But stack smashing is only widely deployed against x86.

Just since x86 is so popular.

>> 2) It breaks trampoline code

> No it does NOT! DIE DIE DIE!!!!

It does. It DOES. IT DOES.

> ARGH. If it completely blocked execution on the stack, syscalls wouldn't
> even work. It does not do that. What it does do, is it traps stack
> exectution, and then analyizes the situation.

Yes. And then you should change kernel to accomodate changes in GCC, GNAT,
GPC, FPK and so on. No, thanks.

> Trampolines work fine!

As far as kernel part is aware about them. Not about existance of trampolines
but about particular version of trampolines used in this and that compiler.

> This is the same garbage arguments that occured two or so years ago when
> Solar's patch first came out. It wasn't true then, it isn't true now.

It was true then and it's true now. Yes, some trampolines works fine. Some
does not. Last thing needed in kernel is AI :-(

>> 3) It doesn't provide full protection
> Nor does a root password.

>> 4) It does raise the bar significantly, in that it stops script kiddies
> True.

It does it only when not widely deployed :-)

>> 5) Most modern daemons are smart enough to switch to unprivileged UIDs when
>> parsing user input, and use strnxxx library functions.

> This doesn't just protect daemons. Look at MSwindows, they are getting
> applications stack smashed (like IE and Outlook) to put malicious code on
> the systems. Linux isn't far off. Sure it's not root access, but as more
> 'users' use Linux root becomes less important. And obtaining root isn't
> hard if you get access as a user who SUes to root.

If user is dumb he deserve to lose.

>> I would say that all considered, it is not worthwhile unless you need to run
>> a bunch of old setuid programs. In that case, you are taking a big risk even
>> with the patch.

> True.

> The big advantage here is that it buys you some time and makes the attack
> a little harder. Right now, even if you are a security junky, and have a
> pager set to page you when a cert alert comes out for your OS.. It still
> takes you time to get out of bed and install it on your systems. In that
> time, you could be auto-rooted a thousand times over by people who scoped
> out your configuration automatically, months ago.

And it'll be true with or without subj.

> Now.. The only question left in my mind: Which is better, stackguard
> compiling all apps by default, or this patch?

Both stackguard and subj is "security via obscurity". It works. Until it's
widely deployed and all cracks are accomodated. So it works now EXACTLY since
it's not default option in kernel.

> With the patch, you dont have to recompile anything, but thats the only
> basis I know for comparison.

But you should patch and recompile kernel while trying to use new version
of GNAT or FPK or ... You got the idea. To me such things do not belong to
standard kernel.

-
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/