4 ms·

Well, since we're talking about 16 bit software ... In 1991, my company was sandboxing commercial software. This was for try-before-you-buy. Except, instead of

by musesum 10y ago

Well, since we're talking about 16 bit software ... In 1991, my company was sandboxing commercial software. This was for try-before-you-buy. Except, instead of recompiling a crippled version, we would take a retail SKU, encipher the executables and then deliver with a device driver: a VxD. The VxD would hook the low level Int13 IO calls to pass all disk IO through a write-through cache. The installed app could read from anywhere on the disk. But, all attempts to write would copy the changed sectors to the cache. This would allow a perfect uninstall; simply remove the cache and the disk reverts back to its preinstalled state. This was because most software, back in 1991, assumed that you'd never want to uninstall. So, it would scatter its junk all over the place. Now imagine if the VxD was part of the OS. Any downloaded exe could access the HD, but all writes would write-through to a separate cache. That was 25 years ago. This is a roundabout way of asking: how feasible is sandboxing to avoid malware?

geofft 10y ago
The Linux machines in MIT's computer labs do essentially the same thing. Right after you log in, there's a wrapper around your entire X session that union-mounts a tmpfs on top of the root filesystem, puts you in that chroot, and gives you root. It's not secure against active malice (and not intended to be, since you have physical access to the machine), but it lets people run `sudo pip install` or `sudo npm install -g` or `sudo make install` or whatever, and it only stays around until they log out. The trouble with root access is that there's always a way for active malice to get in. For instance, our approach is trivially vulnerable to loading a kernel module. It's possible that something like user namespaces would solve that today.
- marmight 10y ago
  Are you sure it's not even more trivially vulnerable than that? From man 2 chroot: This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a "chroot jail" by doing: mkdir foo; chroot foo; cd ..
  - andrewchambers 10y 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.
    - marmight 10y 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.
      - comex 10y 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).
        geofft 10y 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.
    - geofft 10y 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.
rzzzt 10y ago
In the Windows XP era, there was SteadyState: https://en.wikipedia.org/wiki/Windows_SteadyState https://en.wikipedia.org/wiki/Windows_SteadyState
- musesum 10y ago
  Aha, looks like SteadyState accomplishes the same thing. Very cool! I wonder how a Windows Restore Point is defeated? Because it is in the same partition?
  - rzzzt 10y ago
    Malware can disable System Restore and delete existing restore points if the user account they are running under has the rights to do so. I think the Cryptolocker variants did this, but not sure...
tfigment 10y ago
Windows Embedded has the Enhanced Write Filter can be enabled to redirect all writes to a disk to memory. You optionally use an admin tool to commit changes on a clean reboot. Many years ago one of our embedded PCs got Conficker from a Service techs laptop. Rebooting the machine was enough to restore it to clean state since nothing was written to disk. Not a solution for everyone but its somewhat similar.
zapt02 10y ago
Look into Sandboxie. It provides a similar (albeit more complicated) approach for modern version of Windows.
vog 10y ago
There's OverlayFS. It does exactly what you want, although it was created for different use cases (Live CDs, layered images as used by Docker, etc.): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.txt https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....

by musesum 10y ago

geofft 10y ago

The Linux machines in MIT's computer labs do essentially the same thing. Right after you log in, there's a wrapper around your entire X session that union-mounts a tmpfs on top of the root filesystem, puts you in that chroot, and gives you root. It's not secure against active malice (and not intended to be, since you have physical access to the machine), but it lets people run `sudo pip install` or `sudo npm install -g` or `sudo make install` or whatever, and it only stays around until they log out. The trouble with root access is that there's always a way for active malice to get in. For instance, our approach is trivially vulnerable to loading a kernel module. It's possible that something like user namespaces would solve that today.

marmight 10y ago
Are you sure it's not even more trivially vulnerable than that? From man 2 chroot: This call does not change the current working directory, so that after the call '.' can be outside the tree rooted at '/'. In particular, the superuser can escape from a "chroot jail" by doing: mkdir foo; chroot foo; cd ..
- andrewchambers 10y 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.
  - marmight 10y 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.
    - comex 10y 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).
      - geofft 10y 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.
  - geofft 10y 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.

rzzzt 10y ago

In the Windows XP era, there was SteadyState: https://en.wikipedia.org/wiki/Windows_SteadyState https://en.wikipedia.org/wiki/Windows_SteadyState

musesum 10y ago
Aha, looks like SteadyState accomplishes the same thing. Very cool! I wonder how a Windows Restore Point is defeated? Because it is in the same partition?
- rzzzt 10y ago
  Malware can disable System Restore and delete existing restore points if the user account they are running under has the rights to do so. I think the Cryptolocker variants did this, but not sure...

tfigment 10y ago

Windows Embedded has the Enhanced Write Filter can be enabled to redirect all writes to a disk to memory. You optionally use an admin tool to commit changes on a clean reboot. Many years ago one of our embedded PCs got Conficker from a Service techs laptop. Rebooting the machine was enough to restore it to clean state since nothing was written to disk. Not a solution for everyone but its somewhat similar.

zapt02 10y ago

Look into Sandboxie. It provides a similar (albeit more complicated) approach for modern version of Windows.

vog 10y ago

There's OverlayFS. It does exactly what you want, although it was created for different use cases (Live CDs, layered images as used by Docker, etc.): https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.txt https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....