Re: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds

Linus Torvalds (torvalds@transmeta.com)
Tue, 4 Aug 1998 20:38:19 -0700 (PDT)


On Tue, 4 Aug 1998 linker@z.ml.org wrote:
>
> Because not all apps are maintained. It's sometimes hard to track these
> things down. Look at the results of the Linux security auditing team, they
> are doing great stuff, but there are only so many hours in a day. I expect
> that even with good luck it will be a year or two before 95% of the
> current overflows are fixed.

I've heard this argument a hundred times now, and it doesn't hold water.

> Think of a ISP shell computer, It's being constantly attacked. Assume
> stupid hackers who dont find anything orignal but do know enought to read
> bugtrack and modify an existing exploit. You've got 2500 users
> and a new exploit arrives on bugtrack at 6PM.

And what if that new exploit overcomes the no-stack-exec stuff?

You (and others) say that crackers are stupid, and can only copy other
peoples exploits. That still means that there needs to be just _one_
person who writes an exploit to get a root shell through portmap or
something. At which point the no-stack-exec patch is completely and
utterly useless.

What do you do then? You're back to square one, and NOTHING you have done
has helped you in the least.

If instead of even counting on the no-stack-exec patch you would have
tried to fix one or two applications, at least you'd have made progress.

In short, my argument is not that the kernel should not try to make things
secure for you. My argument is that no-stack-exec adds nada, zero, zilch,
nothing in the form or real security. With one simple change to some
exploit, you're suddenly wide open.

No, you may not be open to old exploits if you have the no-stack-exec
patch. But old and known stack exploits aren't the issue: those are easy
to fix in user space anyway.

Linus

-
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.altern.org/andrebalsa/doc/lkml-faq.html