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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20101019161142.38EF.0@argo.troja.mff.cuni.cz>
Date: Tue, 19 Oct 2010 21:29:00 +0200 (MET DST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: The GNU C library dynamic linker expands
 $ORIGIN in setuid library search path

On Mon, 18 Oct 2010, Marsh Ray wrote:

> > 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.

It does not mean they are entitled to ram it down everyone's throat. :P

> > -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.

Indeed. It was not supposed to be an analogy; it occurred to me people who
like to tempt the fate one way would enjoy doing it another way too. :)

> > Or perhaps it can be controlled by a configuration file in /etc.
> Can I control that with chroot? User installable filesystems? etc.

Some filesystem paths have to be trusted--starting with /lib where the
dynamic linker itself is located. In fact, /etc is already trusted by
Glib's ld.so because it loads /etc/ld.so.cache and uses it to locate
standard dynamic libraries.

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

Environment variables are much more insidious than arguments. In a typical
program the flow of input data passed as arguments is under control while
inputs passed as the environment are available everywhere (the same holds
for the environment in the broader sense, including open file handles,
files in the current working directory etc.).

And it would probably be much more challenging to write down a meaningful
whitelist for command line arguments than for environment variables. (It
might be worth trying anyway.)

> 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.

Much of that can be emulated with type enforcement in SELinux.
You can associate execution of a set*id program with a transition to a
domain whose privilege to execute files is restricted.

-- 
Pavel Kankovsky aka Peak                          / Jeremiah 9:21        \
"For death is come up into our MS Windows(tm)..." \ 21st century edition /

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