Hacker News Reader

Comment by aloknnikhil | Hacker News Reader

Wait, are there people who really think chroot offers security?

I mean, at least read the man page before making assumptions?

http://man7.org/linux/man-pages/man2/chroot.2.html

> This call changes an ingredient in the pathname resolution process and does nothing else.

> It is not intended to be used for any kind of security purpose, neither to fully sandbox a process nor to restrict filesystem system calls.

> In particular, the superuser can escape from a "chroot jail" by doing: mkdir foo; chroot foo; cd ..

> However, if a folder is moved out of the chroot directory, an attacker can exploit that to get out of the chroot directory as well. The easiest way to do that is to chdir(2) to the to-be-moved directory, wait for it to be moved out, then open a path like ../../../etc/passwd.

EDIT: Fixed link to a more up-to-date man page. They explicitly call this out as not being a security feature in the updated man page.

View on HN

On BSD, jail() is used as an extension to chroot() specifically to improve the security for externally accessible services. Breaking into ftpd (jail() has been around that long) would only give an attacker access to the configured subdirectory, and not /etc/passwd and shadow.

The reason chroot() isn't a security feature is because Linux only half copied/re-implemented that feature. Properly implemented, it's a decent idea.

I was left to wonder if chroot along with a well-crafted SELinux policy might get one closer to security nirvana.

i often wondered how exactly one can escape from a chroot but never really tried or read that man page until now. I tried the above and it did not work as described. I tried both changing to the parent directory directly after chroot and chrooting inside the chroot and doing it then.

Edit: Now that i really read that page i realized 2 things, first this page is about the syscall and not the command and second it says the syscall itself does not change the current directory to the provided path. I guess the chroot command does just that and this is why it did not work as described. The example given literally still does not work as advertised.

This is the more correct escape (EDIT: and works today):

  fd = open(".", O_PATH);
  chroot("foo");
  fchdir(fd); // escaped to "." and chroot no longer blocks ".." past "/"
  chdir("../../../../"); // go to real "/"
  chroot("."); // broken out

The "chdir .." trick used to work a long time ago. The man page probably hasn't been updated in ~20 years.

Not really an issue. If there's an fd pointing outside of the chroot, of course it's possible to do stuff outside of it. That with a path FD a total escape is possible isn't that obvious, but not unexpected.

Well, it is an issue if you can use it to break out of containers that use --no-pivot-root (you can). fd-related escapes are possible for pivot_root(2) but are usually not as trivial as the one for chroot(2).

Also there are other attacks against chroot(2) which don't make use of fd-related escapes (nd->root protections in pathname lookup are very minimal and there are lots of ways to trick them).

This progam is bugged as you're relying on file pointer aquired before the chroot.

Imagine this program was running within a chroot(2) that it didn't set up. You can nest a chroot(2) and break out -- that was the point I was making.

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.

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

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

Alright, 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.

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

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

Just to make sure I understand what's happening here:

1) a direct chroot("../../../") would not work, as the kernel restricts ../ to / if at the chroot-root.

2) chroots are not nested.

3) By making a handle to a path, then chrooting, the security measure 1) is disabled for that handle (as it's outside of the current chroot), and the kernel doesn't keep track that it was created in an earlier chroot.

Is that right?

(1) is mostly right. The actual restriction is that ".." will be a no-op if the current directory is equal to nd->root (what your current root is).

(2) Yes, each process only has one root at a time.

(3) The restrictions don't apply to file handles at all (an fd doesn't know what chroot it was created in). Instead what happens is that the restriction in (1) is useless once the current directory of the resolution is above the nd->root (after all, a directory above nd->root is not equal to nd->root).

Ah, thanks I think I got it now. That's indeed trivial to execute as long as one still can do chroot.

to be clear, neither will work on a reasonably modern system?

No, the above escape will definitely work on a modern system.

Thanks that was quite helpful.

> Wait, are there people who really think chroot offers security?

The real answer is that this is a bad question. chroot disables some attack vectors. For example a path traversal vulnerability in a reverse http proxy is almost entirely mitigated by putting the proxy in a chroot. There may be extra details like access to cache or configuration, but chroot largely prevents harm from that issue. It does little against people with local access. So basically - it's more nuanced. "X offers security" is a trap.

But isn't chroot typically used by normal users anyway ?

Maybe were you thinking about fakeroot ?

"fakeroot runs a command in an environment wherein it appears to have root privileges for file manipulation. This is useful for allowing users to create archives (tar, ar, .deb etc.) with files in them with root permissions/ownership."

https://man.cx/fakeroot(1)

chroot(2) requires privileges (CAP_SYS_CHROOT on Linux). Otherwise you could trick setuid binaries into doing some pretty bad things.

The same that keep writing security critical code in C, without any kind of static analysers and code fuzzing as part of their build.

Reply on news.ycombinator.com