Yes, this can be done by overwriting libc calls or patching httpd
process at runtime to overwrite open() at libc address map, and get
open() calls trapped just for apache. BUT, let's figure a scenario: GD
has a buffer overflow bug that when it tries to get the size of a
existing malformed image (that can be uploaded by any user at web
app), it segfaults. It's a exploitable bug, and a attacker sucessfully
exploit it, binding a shell. Shellcodes don't make use of libc calls.
Instead, they use direct asm calls to trigger system calls that they
need to use (execve(), dup() for example of a connect-back shellcode).
Your method will not trigger that exploitation, but a kernel-level
wrapper will see that "/bin/sh" got executed by httpd, what is...
unacceptable. Yes, I can patch the whole libc and expect when the
attacker issue any "ls -la" that WILL be triggered by your patched
libc wrapper. But I dont like userland patches like that (in fact, I
prefer to avoid libc hackings like that). Imagine a libc wrapper that
inside a read(), it makes a syslog() or anything to log... a simple
strace will catch it up.
Returning to the topic context... the kernel sees everything. Libc
just accept that and live with, as a wife =) I prefer to be the
husband one...
--
# (perl -e "while (1) { print "\x90"; }") | dd of=/dev/evil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
