The GNU C library dynamic linker expands $ORIGIN in setuid library search path

[Hanno Böck]

# Open a file descriptor to the target binary (note: some users are
surprised # to learn exec can be used to manipulate the redirections of
the current # shell if a command is not specified. This is what is
happening below).
$ exec 3< /tmp/exploit/target

I tried to reproduce this on Gentoo and it fails at this point. It seems the
reason is that suid-binaries are not world-readable on Gentoo (on Debian they
are) - this seems to be a useful security measure.

[Pavel Kankovsky]

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.

[Tavis Ormandy]

Post by Hanno Böck

# Open a file descriptor to the target binary (note: some users are
surprised # to learn exec can be used to manipulate the redirections of
the current # shell if a command is not specified. This is what is
happening below). $ exec 3< /tmp/exploit/target

I tried to reproduce this on Gentoo and it fails at this point. It seems
the reason is that suid-binaries are not world-readable on Gentoo (on
Debian they are) - this seems to be a useful security measure.

Hi Hanno, I explained why this is insufficient in the Notes section of my
advisory, along with some example code to circumvent this.

Tavis.

[Louis Granboulan]

Am I the only one that thinks that the problem is in the way that Linux
defines the semantics of /proc/nnn/fd/n ?
I only think of three sensible ways of doing it.

One could follow exactly what is in the man page, and /proc/nnn/fd/n are
symbolic links to actual files.
Then, if the file is deleted or moved, the link points to nothing. And if
the file is replaced, it points to the new file.
Of course, the drawback is that /proc/nnn/fd/n is not reliably pointing to
the opened file. But that's normal, for a symbolic link.

The second option would have to be /proc/nnn/fd/n a special file rather than
a symbolic link, that behaves exactly like the file descriptor. This special
file would be accessible with exactly the same rights as the ones used to
open the file. For example, if one does
$ exec 3>/tmp/toto; echo tata>&3
then of course we would be able to do
$ cat /tmp/toto
but we would get "Permission denied" when trying
$ cat /proc/self/fd/3
One side effect would be that /proc/nnn/fd/n would never be setuid.
Additionnally, doing
$ echo tutu>/proc/self/fd/3
would append at the end of /tmp/toto, because it would be the same as
$ echo tutu>&3
and not
$ echo tutu>/tmp/toto

The third option, which is the closest to the current semantics, is to have
/proc/xxx/fd/x to be a symbolic link to the file currently in use.
Therefore, like it is the case in Linux, if the file is moved, the symbolic
link is changed (I did not check if there is a race condition there).
But, if the file is deleted, then the symbolic link needs to be a link to an
actual file. The best is probably to use the same trick as for NFS: to
generate a file with a random unique name in the root of the filesystem.
However, it is quite clear to me that the current behaviour is inconsistent
and is the reason of this security flaw. We see
$ ls -l /proc/self/fd/3
pretend that it is a symbolic link to a file that does not exist, and
$ ls -lL /proc/self/fd/3
show a setuid file.

[Tavis Ormandy]

Post by Louis Granboulan
However, it is quite clear to me that the current behaviour is
inconsistent and is the reason of this security flaw. We see $ ls -l
/proc/self/fd/3 pretend that it is a symbolic link to a file that does not
exist, and $ ls -lL /proc/self/fd/3 show a setuid file.

Louis, the commands specified in the advisory were intended to help
illustrate the problem, not be a replacement for any analysis. Your
questions were anticipated, and answered in the Notes section.

Next time I will put the Notes section at the top ;-)

Tavis.