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

[Marsh Ray <marsh@xxxxxxxxxxxxxxxxxx>]

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/