9

Why is chroot(2) unavailable to unprivileged users?

I don't understand existing answers on the Internet. For example this one https://lists.freebsd.org/pipermail/freebsd-security/2003-April/000123.html.

Would sudo really work if /etc/sudoers and /etc were not owned by root? An unprivileged user can't just create root owned setuid binaries inside chroot, can she?

Exactly how can an unprivileged user subvert the chroot environment?

I can only think of something like that

ln /mnt/backup/XYZ/etc/sudoers $CHROOT/etc/sudoers
ln /usr/bin/sudo $CHROOT/usr/bin/sudo

where XYZ denotes some backup instance where admin really screwed up and allowed my user something dangerous. But this is kinda special. Is there any more straightforward way to exploit chroot(2) if it was available to unprivileged users?

Gilles 'SO- stop being evil'
  • 829,060
woky
  • 432

3 Answers3

6

chroot(2) does not change the working directory, so after the call . can be outside of the tree rooted at /. You can then run any setuid binary from inside the chroot by using a relative path. There are probably many ways to exploit this. For example by modifying /etc/ld.so.preload inside your chroot directory you can execute arbitrary code with root privileges. You can have a look at an example.

Friedrich
  • 199
4

An ordinary user can't create a setuid binary, but there's nothing preventing him from creating a hard link to an existing setuid binary. So if he has write permission to a directory on the same filesystem as /usr/bin, he can put the jail in this directory, create a hard link to su or sudo in it, and put a custom /etc/passwd and /etc/sudoers in the jail.

Maybe that won't work for sudo, as it might check that /etc/sudoers is owned by root. But I'll bet su doesn't check the ownership of /etc/passwd.

Barmar
  • 9,927
  • This in no longer an issue in Linux 3.6 and later, where the creation of hardlinks requires the user to own the existing file or have read/write access to it. See https://lore.kernel.org/patchwork/patch/315952/. – Friedrich Mar 25 '19 at 17:17
4

According to Brad Spengler on https://forums.grsecurity.net/viewtopic.php?f=7&t=2522, there is a trivial way to escalate to uid 0 using CAP_SYS_CHROOT (the capability to use chroot(2):

CAP_SYS_CHROOT: generic: From Julien Tinnes/Chris Evans: if you have write access to the same filesystem as a suid root binary, set up a chroot environment with a backdoored libc and then execute a hardlinked suid root binary within your chroot and gain full root privileges through your backdoor

guest
  • 41
  • This in no longer an issue in Linux 3.6 and later, where the creation of hardlinks requires the user to own the existing file or have read/write access to it. See https://lore.kernel.org/patchwork/patch/315952/. – Friedrich Mar 25 '19 at 17:18