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 programThe 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/
Current thread:
- The GNU C library dynamic linker expands $ORIGIN in setuid library search path Tavis Ormandy (Oct 18)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Pavel Kankovsky (Oct 18)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Marsh Ray (Oct 18)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Pavel Kankovsky (Oct 19)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Marsh Ray (Oct 18)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Hanno Böck (Oct 19)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Tavis Ormandy (Oct 19)
- <Possible follow-ups>
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Louis Granboulan (Oct 20)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Tavis Ormandy (Oct 20)
- Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path Pavel Kankovsky (Oct 18)