mailing list archives
Re: The GNU C library dynamic linker expands $ORIGIN in setuid library search path
From: Marsh Ray <marsh () extendedsubset com>
Date: Mon, 18 Oct 2010 14:36:48 -0500
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
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
+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.
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/