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/..._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 ro 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