On Sun, 1 Apr 2007, Pavel Kankovsky wrote:
> You do not have to rely on some other user running your trojan horse.
> You can replace a program run automatically (e.g. by cron). Or something
> even better: replace system dynamic libraries (e.g. /lib/tls) and run a
> dynamically linked setuid program of your own choice. Instant ownage!
> (Moreover, the latter approach is quite easy to exploit without making
> the system unusable.)
>
> This is a very serious vulnerability.
I absolutely agree.
Here's a proof of concept exploit i wrote to demonstrate a specific local
privilege escalation scenario (there's plenty of other attack vectors that
can be used, see comments in the script for a brief list of the most
obvious ones):
http://www.0xdeadbeef.info/exploits/raptor_truecrypt.tgz
WARNING: DO NOT USE IT IF YOU DON'T KNOW WHAT YOU'RE DOING, IT CAN
SEVERELY SCREW UP YOUR SYSTEM!
By the way, writing the exploit i noticed this (flawed?) behaviour of
ld.so(8). From its man page:
LD_PRELOAD
A whitespace-separated list of additional, user-specified, ELF
shared libraries to be loaded before all others. This can be
used to selectively override functions in other shared
libraries. For set-user-ID/set-group-ID ELF binaries, only
libraries in the standard search directories that are also set-
user-ID will be loaded.
So far, so good. But the libraries do not have to be setuid root: they
just need the setuid bit set and the owner can also be an unprivileged
user. This may have some small security implications: i suppose an
additional check on the ownership of the libraries wouldn't hurt here.
Cheers,
--
Marco Ivaldi
Antifork Research, Inc. http://0xdeadbeef.info/
3B05 C9C5 A2DE C3D7 4233 0394 EF85 2008 DBFD B707