17 ms·

There are several more ways you can escape chroot(2) through VFS attacks (nd->root protections are very minimal). However, the more important point should be t

by cyphar 7y ago

There are several more ways you can escape chroot(2) through VFS attacks (nd->root protections are very minimal). However, the more important point should be that there is a similar syscall which doesn't have the same flaws as chroot(2) because the protection is based on mount namespaces -- pivot_root(2). The problem with chroot(2) is that the mountpoints above "/" are still accessible by the VFS internally. pivot_root(2) gets rid of the mounts and so VFS won't reach them anymore.

e12e 7y ago
I see there's a similar wrapper binary - but apparently you need to both pivot and chroot? https://linux.die.net/man/8/pivot_root https://linux.die.net/man/8/pivot_root
- cyphar 7y ago
  The man page is out-dated (and Michael Kerrisk has posted on LKML that he plans to rewrite it). You don't need to do chroot("/") -- that operation makes no sense because there is no semantic difference between chroot("/") and doing nothing (even the kernel can't distinguish the two cases). What you need to do is the following: mkdir newroot/oldroot mount --rbind newroot newroot # if newroot isn't a mountpoint pivot_root newroot oldroot cd / # and now get rid of the old root's mounts mount --make-rslave oldroot umount -lR oldroot At least, approximately. There is a more clever way to do it by doing "pivot_root . ."[1] but posting that here just makes it more confusing. As a complete aside, this is what container runtimes do when switching to the container rootfs -- and is the main reason why --no-pivot-root is incredibly insecure (because it uses chroot). [1]: https://github.com/opencontainers/runc/blob/v1.0.0-rc8/libcontainer/rootfs_linux.go#L700-L757 https://github.com/opencontainers/runc/blob/v1.0.0-rc8/libco...
tinus_hn 7y ago
So what are these mystical ‘several ways’, preferably some that do not require root and not require proc mounted in the chroot?
- dividuum 7y ago
  I can think of ptrace() attach to other processes of the same user outside of the chroot environment and inject arbitrary code.
  - theamk 7y ago
    In modern systems, ptrace requires root even if attaching to the same user. So this hole has been closed.
ori_b 7y ago
> pivot_root(2) gets rid of the mounts and so VFS won't reach them anymore. So what happens to open FDs, like the FD for the binary you are executing?
- cyphar 7y ago
  I should've added "with the exception of magic-links", which effectively bypass VFS's resolution. Yes, if you get a file descriptor from a foreign namespace then you can make use of it for various escapes. Unfortunately there really aren't many protections against this type of thing. Though, /proc/self/exe alone won't give you resolution access to the host. It takes a bit more work and more bugs.
  - ori_b 7y ago
    Alright, how about a more useful example: I open a file in the users home directory and then drop my namespace to /var/void to prevent myself from opening any additional files? This is a very common pattern, and killing off open FDs seems like a very wrong thing to do.
    - cyphar 7y ago
      The correct thing to do is bind-mount the user's home directory, pivot_root(2) and then open the files you need. That way, file descriptors opened in the user's home directory aren't from a namespace where the host's root is reachable. Introducing a foreign file descriptor (unless you really know what you're doing) is a bug, assuming your goal is to be secure against escapes. Even AppArmor would struggle to protect you from this.
      - ori_b 7y ago
        Leaving the home directory accessible is the exact problem that needs to be solved. An attacker doesn't need to break out of a sandbox to access the rest of my system: they can download it from debian.org. Being able to open new files after initialization is a bug. The solution is to initialize the application before it can touch untrusted input, and then drop any ability to do anything other than process the resources set up in the init phase. The program will ideally be running in a completely empty namespace when handling untrusted data. You can think of FDs as capabilities. Dropping the namespace prevents the program from requesting new capabilities. It's perverse to tie owning capabilities to being able to request new ones.

by cyphar 7y ago

e12e 7y ago

I see there's a similar wrapper binary - but apparently you need to both pivot and chroot? https://linux.die.net/man/8/pivot_root https://linux.die.net/man/8/pivot_root

cyphar 7y ago
The man page is out-dated (and Michael Kerrisk has posted on LKML that he plans to rewrite it). You don't need to do chroot("/") -- that operation makes no sense because there is no semantic difference between chroot("/") and doing nothing (even the kernel can't distinguish the two cases). What you need to do is the following: mkdir newroot/oldroot mount --rbind newroot newroot # if newroot isn't a mountpoint pivot_root newroot oldroot cd / # and now get rid of the old root's mounts mount --make-rslave oldroot umount -lR oldroot At least, approximately. There is a more clever way to do it by doing "pivot_root . ."[1] but posting that here just makes it more confusing. As a complete aside, this is what container runtimes do when switching to the container rootfs -- and is the main reason why --no-pivot-root is incredibly insecure (because it uses chroot). [1]: https://github.com/opencontainers/runc/blob/v1.0.0-rc8/libcontainer/rootfs_linux.go#L700-L757 https://github.com/opencontainers/runc/blob/v1.0.0-rc8/libco...

tinus_hn 7y ago

So what are these mystical ‘several ways’, preferably some that do not require root and not require proc mounted in the chroot?

dividuum 7y ago
I can think of ptrace() attach to other processes of the same user outside of the chroot environment and inject arbitrary code.
- theamk 7y ago
  In modern systems, ptrace requires root even if attaching to the same user. So this hole has been closed.

ori_b 7y ago

> pivot_root(2) gets rid of the mounts and so VFS won't reach them anymore. So what happens to open FDs, like the FD for the binary you are executing?

cyphar 7y ago
I should've added "with the exception of magic-links", which effectively bypass VFS's resolution. Yes, if you get a file descriptor from a foreign namespace then you can make use of it for various escapes. Unfortunately there really aren't many protections against this type of thing. Though, /proc/self/exe alone won't give you resolution access to the host. It takes a bit more work and more bugs.
- ori_b 7y ago
  Alright, how about a more useful example: I open a file in the users home directory and then drop my namespace to /var/void to prevent myself from opening any additional files? This is a very common pattern, and killing off open FDs seems like a very wrong thing to do.
  - cyphar 7y ago
    The correct thing to do is bind-mount the user's home directory, pivot_root(2) and then open the files you need. That way, file descriptors opened in the user's home directory aren't from a namespace where the host's root is reachable. Introducing a foreign file descriptor (unless you really know what you're doing) is a bug, assuming your goal is to be secure against escapes. Even AppArmor would struggle to protect you from this.
    - ori_b 7y ago
      Leaving the home directory accessible is the exact problem that needs to be solved. An attacker doesn't need to break out of a sandbox to access the rest of my system: they can download it from debian.org. Being able to open new files after initialization is a bug. The solution is to initialize the application before it can touch untrusted input, and then drop any ability to do anything other than process the resources set up in the init phase. The program will ideally be running in a completely empty namespace when handling untrusted data. You can think of FDs as capabilities. Dropping the namespace prevents the program from requesting new capabilities. It's perverse to tie owning capabilities to being able to request new ones.