Linux-kernel mailing list archive 2000-29,: Re: I QUIT (Re: IDE drive killer question)

# Re: I QUIT (Re: IDE drive killer question)

David Luyer (david_luyer@pacific.net.au)
Sat, 22 Jul 2000 15:08:25 +1000

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Stephen Frost: "Re: scsi-destroyer.c to come..."
- Previous message: Myrddin Emrys: "Re: IDE drive killer question"
- Maybe in reply to: Andre Hedrick: "I QUIT (Re: IDE drive killer question)"

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/

- Next message: Stephen Frost: "Re: scsi-destroyer.c to come..."
- Previous message: Myrddin Emrys: "Re: IDE drive killer question"
- Maybe in reply to: Andre Hedrick: "I QUIT (Re: IDE drive killer question)"