lkml.org 
[lkml]   [1998]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.139 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site