lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: I QUIT (Re: IDE drive killer question)
Date
From

My response here is partly drifting off-topic... but hopefully relevant
enough.

Enrico Demarin wrote:
> The only case where it would help would be to prevent some buffer overflow
> to a root process or some trojan horse to do the dirty job automatically.

The main place it helps is automation - for example if a JPEG were created
containing the exploit in a way it exploited a buffer overflow in the
decompression code of a popular web browser or mail reader for Unix.
Who would blame their hard disk failure on the image on a web site they
just viewed?

Associated with this is traceability, such an image could potentially be
spread through the world's Windows users with no effect until it reaches
the unsuspecting Linux user. On the other hand, active root exploitation
is much more probable to be traceable.

In a buffer overflow to a root process chances are (extremely likely) that
root is already able to be compromised and that if someone is doing this
by hand, it's just a case of someone having stayed up some hours longer
developing the initial exploit. Similarly in the trick root to buffer
overflow bash case, if the hacker is sticking around the same bug would
most likely be exploitable for a SUID shell, just that again it's a higher
risk way of exploiting the bug (more risk of discovery).

There are other places where the "really simple exploit code" helps, for
example to exploit a buffer overflow to do something really nasty on a
system where all drives are marked read-only and most are marked no-exec,
and the buffer overflow in question doesn't present a reasonable opportunity
to insert large amounts of arbitrary code (clears out its environment,
rewrites its argv, takes no input into its own memory space before the
point of exploitation, etc, etc). But that's a real corner case on a
system which most likely would already be restricting things down hard with
capabilities these days... leading on to:

Requiring CAP_RAW_IO is where I really see this sitting - since once the
hacker has CAP_RAW_IO all bets are off. The ability to directly modify
memory and insert modules are relevant too, however these are really
"capability defeating" abilities which are already assumed to be removed
in a secured system before CAP_RAW_IO.

David.
--
----------------------------------------------
David Luyer
Senior Network Engineer
Pacific Internet (Aust) Pty Ltd
Phone: +61 3 9674 7525
Fax: +61 3 9699 8693
Mobile: +61 4 1064 2258, +61 4 1114 2258
http://www.pacific.net.au NASDAQ: PCNTF
<< fast 'n easy >>
----------------------------------------------



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

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