Messages in this thread | | | Date | Sat, 8 Aug 1998 02:37:07 -0400 (EDT) | From | Jon Lewis <> | Subject | Re: [PATCH] [SECURITY] suid procs exec'd with bad 0,1,2 fds |
| |
On Fri, 7 Aug 1998, Linus Torvalds wrote:
> And yet, the arguments that people have had in favour of no-stack-exec is > that it protects you against these well-known exploits - and that hackers > are too stupid to come up with new ones.
That's not the point being argued. The sort of people who go out and get/apply the secure-linux patch are not the sort who knowingly leave holey apps on their systems...at least I'd guess most are not. The point is, that if today, some cracker finds that cucipop (sorry SRB:) is vulnerable to a remote buffer overflow attack, there's a good chance they'll write a simple exploit using Aleph One's "Smashing The Stack For Fun And Profit" as a guide, exploit some systems, and trade the exploit with their friends. If someone tries it against me, all kinds of alarms go off, they don't get root, I know I have a security problem to track down, and they move on to easier victims...maybe FreeBSD systems. :)
> You can't have it both ways. Either the problem is old exploits (in which > case the kernel hack is just plain wrong, as the real bugs are also > known), or the problem is new exploits that haven't been used yet (in > which case the kernel hack is not sufficient protection anyway).
Yes it is...because the new exploits are almost certainly just variations on a very old theme. Same attack methods...different daemon/suid program.
> Yes, the kernel hack can protect you against a limited form of old-style > but not yet known exploits. However, I still claim that it's better to > find them the hard way rather than not find them at all, and I also claim ^^^^^^^^^^^^^^^^^^^^ That's not an issue either. If a buffer overflow is caught, the system complains and logs info about it. You get to find the new bugs _and_ avoid being rooted.
> that making the no-stack-exec patch the default wouldn't help anyway, > because it would just mean that the crackers who _do_ come up with new > ideas would take it into account by default, and then the protection is
That's the only downside I see. If there are ways around the patch, and if it were to become standard, all new exploits for linux would have to take no-stack-exec into account and attempt to work around it. I'm not sure there's an easy way around no-stack-exec that doesn't require lots of trial and error, meaning a cracker would likely be caught before they get far.
> The ONLY reason I see for the kernel hack is to allow people to ignore > certain known security holes in user space. And that's a really bad reason > in my book.
No...it's to protect against the next currently unknown hole discovered that we've all had for the past X years.
> personally think that it is a bad thing to have in the kernel, and I won't > accept it in the tree _I_ maintain until somebody can come up with better > arguments than I've heard so far.
I could respect that if your arguments didn't seem to be based mostly on misconception or misunderstanding. No offense intended.
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Spammers will be winnuked or Network Administrator | drawn and quartered...whichever Florida Digital Turnpike | is more convenient. ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
- 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
| |