5 ms·

Chw00t: Breaking Unices’ chroot solutions

27 points by mulander 11y ago

liveoneggs 11y ago
go go netbsd
- bch 11y ago
  Yes, very interesting. I assume I'm reading it correctly that NetBSD was immune to all tested faults (and Debian was susceptible to all)?
gruez 11y ago
'unices' is the plural of unix? TIL.
- MichaelBurge 11y ago
  ox -> oxen unix -> unixen emacs -> emacsen
  - wiml 11y ago
    Interestingly, I have never seen "emaces" suggested as a plural of emacs, despite emacs-era hackers' propensity to play with plurals (and other affixes).
    - qbrass 11y ago
      http://www.emacswiki.org/emacs/plural.el http://www.emacswiki.org/emacs/plural.el ("emacs" "emacsen")
      - boyaka 11y ago
        I'm learning a lot about plurals there...Media is a plural of medium...This should have been obvious but I never thought about it.
sdkmvx 11y ago
Since Slideshare is completely broken, this is available in PDF form (along with more) at https://github.com/earthquake/chw00t https://github.com/earthquake/chw00t
cbd1984 11y ago
Interesting discussion: https://lwn.net/Articles/252794/ https://lwn.net/Articles/252794/ which links to here: http://web.archive.org/web/20071011110715/http://kerneltrap.org/Linux/Abusing_chroot http://web.archive.org/web/20071011110715/http://kerneltrap.... which further makes the point that chroot is not now and has never been a member of the "security tool" universe. AIUI, containers are meant to be secure against processes (and, therefore, users) that want to get out, so if you care about that, use those, instead.
- geggam 11y ago
  root is root. containers that run as root are no more secure than chroot.. ( see : docker )
  - ithkuil 11y ago
    is this true? I understand that the attack surface of a cgroup based container is bigger than a VM, but saying that just running processes as root in contains is not more secure than chroot begs at least for some reference.
    - tyingq 11y ago
      I believe that "root is root" is just shorthand for... If you aren't using unprivileged containers, then the only approach you have for making the container more secure than chroot is a whack-a-mole style approach. By whack-a-mole, I mean trying to map out the attack surface, and using a hodge podge of tools to try and close them (kernel cap-drops, apparmor, se-linux, firewall rules, overlay mounts for /proc, /sys, etc). I think it's reasonable to say that the whack-a-mole approach isn't truly more secure. In the same way that having a vault door on the front of your house, next to an open window isn't any more secure than having the door wide open.
binarycrusader 11y ago
Eh, this is sort of silly in some respects. chroot is not meant to be a security mechanism (yes, I know the presentation mentions this). The limitations are well known in the OS community. With that said, I agree that many developers mistake chroot's real purpose. Solaris, in particular, offers a far superior solution with zones.
rsync 11y ago
I think chroot can be used as one piece in a defense-in-depth security scheme. I think it is incorrect to make a blanket statement that chroot cannot be used to increase security at all. Further, I think all of the "root needed" exploits (most of them) are irrelevant. If you have root, who cares about defeating a chroot on that system ? You're already root. Finally, I note that the systems I use chroot on (FreeBSD) have almost zero vulnerability (see table on slide 27).
0x0 11y ago
When I clicked this link, apparently SlideShare did some automatic voodoo with my LinkedIn cookie and now there's a public slideshare profile page with my name on it that I cannot delete or unpublish :(
gtirloni 11y ago
I don't know if I'm using this tool incorrectly or if Docker containers contain any measures against what it tries. On a machine running Linux 4.2.7 and a container created with Docker 1.9.1, the tool either failed with an error or said it had broken out but the root was still inside the container. Modes / Result: * -0 / no error, root still inside container * -1 / no error, root still inside container * -2 / no error, root still inside container * -3 / error, "error mounting chroot: Operation not permitted" * -4 / error, "error creating block device: No such file or directory" * -5 / error, "error creating $nestdir" * -6 / not tested * -7 / error, "error attaching process" * -9 / no error, root still inside container

27 points by mulander 11y ago

liveoneggs 11y ago

go go netbsd

bch 11y ago
Yes, very interesting. I assume I'm reading it correctly that NetBSD was immune to all tested faults (and Debian was susceptible to all)?

gruez 11y ago

'unices' is the plural of unix? TIL.

MichaelBurge 11y ago
ox -> oxen unix -> unixen emacs -> emacsen
- wiml 11y ago
  Interestingly, I have never seen "emaces" suggested as a plural of emacs, despite emacs-era hackers' propensity to play with plurals (and other affixes).
  - qbrass 11y ago
    http://www.emacswiki.org/emacs/plural.el http://www.emacswiki.org/emacs/plural.el ("emacs" "emacsen")
    - boyaka 11y ago
      I'm learning a lot about plurals there...Media is a plural of medium...This should have been obvious but I never thought about it.

sdkmvx 11y ago

Since Slideshare is completely broken, this is available in PDF form (along with more) at https://github.com/earthquake/chw00t https://github.com/earthquake/chw00t

cbd1984 11y ago

Interesting discussion: https://lwn.net/Articles/252794/ https://lwn.net/Articles/252794/ which links to here: http://web.archive.org/web/20071011110715/http://kerneltrap.org/Linux/Abusing_chroot http://web.archive.org/web/20071011110715/http://kerneltrap.... which further makes the point that chroot is not now and has never been a member of the "security tool" universe. AIUI, containers are meant to be secure against processes (and, therefore, users) that want to get out, so if you care about that, use those, instead.

geggam 11y ago
root is root. containers that run as root are no more secure than chroot.. ( see : docker )
- ithkuil 11y ago
  is this true? I understand that the attack surface of a cgroup based container is bigger than a VM, but saying that just running processes as root in contains is not more secure than chroot begs at least for some reference.
  - tyingq 11y ago
    I believe that "root is root" is just shorthand for... If you aren't using unprivileged containers, then the only approach you have for making the container more secure than chroot is a whack-a-mole style approach. By whack-a-mole, I mean trying to map out the attack surface, and using a hodge podge of tools to try and close them (kernel cap-drops, apparmor, se-linux, firewall rules, overlay mounts for /proc, /sys, etc). I think it's reasonable to say that the whack-a-mole approach isn't truly more secure. In the same way that having a vault door on the front of your house, next to an open window isn't any more secure than having the door wide open.

binarycrusader 11y ago

Eh, this is sort of silly in some respects. chroot is not meant to be a security mechanism (yes, I know the presentation mentions this). The limitations are well known in the OS community. With that said, I agree that many developers mistake chroot's real purpose. Solaris, in particular, offers a far superior solution with zones.

rsync 11y ago

I think chroot can be used as one piece in a defense-in-depth security scheme. I think it is incorrect to make a blanket statement that chroot cannot be used to increase security at all. Further, I think all of the "root needed" exploits (most of them) are irrelevant. If you have root, who cares about defeating a chroot on that system ? You're already root. Finally, I note that the systems I use chroot on (FreeBSD) have almost zero vulnerability (see table on slide 27).

0x0 11y ago

When I clicked this link, apparently SlideShare did some automatic voodoo with my LinkedIn cookie and now there's a public slideshare profile page with my name on it that I cannot delete or unpublish :(

gtirloni 11y ago

I don't know if I'm using this tool incorrectly or if Docker containers contain any measures against what it tries. On a machine running Linux 4.2.7 and a container created with Docker 1.9.1, the tool either failed with an error or said it had broken out but the root was still inside the container. Modes / Result: * -0 / no error, root still inside container * -1 / no error, root still inside container * -2 / no error, root still inside container * -3 / error, "error mounting chroot: Operation not permitted" * -4 / error, "error creating block device: No such file or directory" * -5 / error, "error creating $nestdir" * -6 / not tested * -7 / error, "error attaching process" * -9 / no error, root still inside container