3 ms·
No, nested chroots do not change anything here. In your example, you would always need to acquire a file descriptor outside the current chroot first. Then such
by raimue 7y ago
No, nested chroots do not change anything here.
In your example, you would always need to acquire a file descriptor outside the current chroot first. Then such a file descriptor has to be passed over some mechanism into the process running in the chroot. For that, you would definitely need help from some other process running outside the chroot. Breaking out a chroot on Linux is not as trivial as you present it.
- cyphar 7y ago> In your example, you would always need to acquire a file descriptor outside the current chroot first. The attack is the following: 0. Process is running in a chroot. 1. Process opens a handle to ".". 2. Process chroot()s to a directory underneath ".". 3. Process chdirs to handle made in (1). 4. Process chdirs to ".." a bunch of times. 5. Process chroot()S to "." which is the host "/". Yes, this requires CAP_SYS_CHROOT (and this is why user namespaces don't work in a chroot -- because breakouts would be trivial). But as I mentioned above there are other VFS-related attacks which are a bit too complicated to get into in a HN comment (they involve RENAME_EXCHANGE and other such fun tricks). But it doesn't require another process to help you. Seriously, just try it.
- raimue 7y agoI would not see this as breaking out of a chroot, because your process already had the file descriptor handle before the chroot system call. Being able to access files that were opened before the chroot call is an intentional feature and used to limit access to a specific set of files.
- davrosthedalek 7y agoNo. The file handle is created after the initial chroot. Then the process chroot again! By fchdir to the file handle, the new AND original chroot are defeated, and a follow up chdir to ../../.. will go to real root.
- Carpetsmoker 7y agoAgain, this is an application bug. It's well known that you need to chdir after chroot and be careful with file pointers acquired before chroot. This behaviour could, arguable, be considered a feature of chroot, albeit a footshoot-y one. Either way, a program behaving in that way is flawed and should be fixed (which is usually not that hard).
- cyphar 7y agoAlright, I'll repeat it one more time. The (attacker's) program is already running inside a chroot -- presumably because they got code execution from some chroot-ed process (after all, chroot is a layer of security right?). The attacker opens a file handle to ".". They then chroot() to a subdirectory. Then they fchdir() relative to the file handle all the way to the host's root. Then they chroot() to the host root. They have now broken out of the original chroot(). I really don't think I can break it down any further.