bugtraq - Re: Denial of Service Vulnerabilities in TrueCrypt 4.3 Linux (re. bid 23180)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Wed, 4 Apr 2007 14:12:07 +0200 (CEST)
From: Marco Ivaldi <raptor@...eadbeef.info>
To: bugtraq@...urityfocus.com
Subject: Re: Denial of Service Vulnerabilities in TrueCrypt 4.3 Linux (re.
 bid 23180)

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