full-disclosure - Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path

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 for Android: free password hash cracker in your pocket

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

Date: Mon, 18 Oct 2010 14:36:48 -0500
From: Marsh Ray <marsh@...endedsubset.com>
To: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: The GNU C library dynamic linker expands
 $ORIGIN in setuid library search path

On 10/18/2010 01:43 PM, Pavel Kankovsky wrote:
 >
> The only sensible restriction for LD_* environment variables (as well as
> many other env. vars.) when a setuid or setgid program is executed is to
> erase all traces of them at the first opportunity.
>
> Those two or three guys who might ever need to execute a set*id program

The problem is that one of those guys writes the Makefile and the other 
two are distro maintainers.

> with LD_PRELOAD or LD_AUDIT or whatever in order to do something other
> than exploit a vulnerability are free to rebuild Glibc with
> -DI_WANT_TO_PLAY_RUSSIAN_ROULETTE.

At least with Russian roulette you can know the odds in advance. In this 
case it's not a probability, it's completely at the option of the 
attacker. If it works, he can be expected to use it.

> Or perhaps it can be controlled by
> a configuration file in /etc.

Can I control that with chroot? User installable filesystems? etc.

> But it is pretty silly to enable it for
> everyone and trade convenience for a very small minority of users
> for extra risk for ALL users.
>
> (To be honest, I would go as far as to propose to erase ANY environment
> variable upon the execution of set*id program. At least unless it is
> allowed EXPLICITLY.)

+1! Environment needs to go through a strict whitelist. Command line too 
while you're at it.

Ideally, set*id executables and every module they load would be signed 
with a system-specific key and required to declare that they're written 
with the intent of being secure for use across an elevated privilege 
boundary like that.

- Marsh

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/