Hacker News new | ask | show | jobs
by andrewchambers 3713 days ago
you have misunderstood what you are reading. man 2 is the library doc not the chroot program, this page is just reminding people to cd into the root otherwise they will be vulnerable.
2 comments
marmight 3713 days ago
You're right insofar as you can't use the chroot command to escape a "chroot jail" because it automatically calls chdir() for you, but any root user can escape one by invoking the following linux system calls:

  chdir("/"); /* go to / of "chroot jail" */
  mkdir("foo", ...); /* create directory in jail */
  chroot("foo"); /* change / to foo */
  /* fail to chdir("foo"); */
  chdir(".."); /* instead go up parent (there is nothing preventing you since you are no longer in the "chroot jail" since the jail is now foo and you never entered it) */
  chdir("..");
  /* ... */
  chdir(".."); /* . is now the real root */
  chroot("."); /* change / to the real root */
This is why the man pages for the linux system call rightfully put "chroot jail" in scare quotes. They are trivially escaped by a root user making basic linux system calls, and the man pages even sketch out how for you. Some operating systems attempt to provide more secure chroot jails, but linux chroot() does not provide this.
link
comex 3712 days ago
> Some operating systems attempt to provide more secure chroot jails, but linux chroot() does not provide this.

Note that this includes Linux itself with CLONE_NEWNS + pivot_root (which is what Docker does).

link
geofft 3712 days ago
Oh! I didn't know Docker used pivot_root, and I was always curious why that call and chroot() both existed. This makes some sense.
link
geofft 3712 days ago
No, parent's understanding is correct. You're thinking of a different (and also valid) attack. Both attacks rely on the fact that the chroot system call remaps the chroot's parent directory to itself (so you can't "cd /; cd .."), but if you are anywhere else, whether inside or outside, no such remapping is performed.

Parent's attack requires the attacker to have root inside the chroot. It's a "double-chroot" attack: you call chroot a second time as root, so a new directory starts getting remapped. Then the old one no longer does, and you can "cd .." out of it and eventually "chroot ." when you get to the top. The only mitigation is not to give an attacker root inside a chroot.

Your attack does not require the attacker to have root. Instead, the process who was setting up the chroot (which does have root) forgets to cd into the chroot, and leaves the working directory outside it. The attacker cannot chroot again, but they can continue to cd anywhere on your filesystem.

link