Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path
From: Pavel Kankovsky <peak () argo troja mff cuni cz>
Date: Tue, 19 Oct 2010 21:29:00 +0200 (MET DST)

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

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/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]