Messages in this thread | | | Subject | Re: I QUIT (Re: IDE drive killer question) | Date | Sat, 22 Jul 2000 15:08:25 +1000 | From | David Luyer <> |
| |
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/
| |