7 ms·

"... in the simplest case a user can mount a Truecrypt volume that contains a file with suid root permission that will open a shell. Golem.de was able to replic

by jmakov 7y ago

"... in the simplest case a user can mount a Truecrypt volume that contains a file with suid root permission that will open a shell. Golem.de was able to replicate this scenario in a current version of Veracrypt."

kuschku 7y ago
Ouch.
bonzini 7y ago
... if you have sudo.
- aasasd 7y ago
  Where does sudo come in with suid executables? Especially since afaik sudo depends on suid in the first place.
  - jlgaddis 7y ago
    One might be granted privileges to mount the filesystem using sudo, but not privileges to run other commands. If the filesystem just mounted has setuid executables, however, the user can then get around their lack of additional sudo privileges by running the setuid executables. Although most people seem to use sudo to allow a user to run anything, that's really not how it was intended to be used.
    - aasasd 7y ago
      That's somewhat different from the Veracrypt case, afaict. And it doesn't seem like this is what bonzini meant by mentioning sudo.
      - bonzini 7y ago
        You still need to gain the privilege to mount filesystems in order to exploit the flaw. So it is a privilege escalation in that you can go from "sudo mount" to a root shell, but it is: 1) not exploitable unless you have sudo 2) pointless if you are authorized to "sudo" any command.
        jeroenhd 7y ago
        This depends on the setup really; it's possible to limit sudo access to only some commands, like so: %veracryptusers ALL=(root) NOPASSWD:/usr/bin/veracrypt An inexperienced systems administrator might use this to allow some users access to the mount command so that users can use their encrypted USB drives to carry around sensitive data, not realizing that through the intricacies of the Linux filesystem this can lead to privilege escalation. Such a config would normally give you sudo, but not a root shell; allowing certain users to use ping floods to test the network by giving them access to the ping command as root, for example, would not expose much security risks other than flooding the network.
        aasasd 7y ago
        I see now that you consider sudo necessary for mounting the filesystem, but a) it seems the point in the report is that Truecrypt allowed to grant this ability without using sudo (I guess either via a daemon or just a setuid executable) b) iirc in case of other filesystems you can allow users to mount them without being root—which is how removable devices work in unixes. So this goes around the whole sudo/setuid system and probably might be another option for this feature in Truecrypt too. Lastly, as jeroenhd noted, even with sudo the root privilege can be granted for a script that mounts a volume, or for one particular command. Sudo, by default, doesn't allow the user to add options to the command specified in `sudoers`.
aasasd 7y ago
This surprised me the most―never thought about this before. Aren't all permission-supporting filesystems vulnerable to this if mounting by a user is permitted? I presume filesystems don't go through the files and downgrade root ownership.
- unixreply55 7y ago
  Yes; that is why it is recommended that untrustworthy drives be mounted with the `nosuid` flag.
  - aasasd 7y ago
    Ah, so even though filesystems don't go through files, they still can block the operation of suid. This suggests then that Veracrypt can simply enable the nosuid option when mounting a device.
    - cyphar 7y ago
      And they should also add nodev, to block a similar attack where you add a bunch of block devices with 777 permissions, in an attempt to make the block device "/" is mounted from be readable to a user and thus able to read (and write) any file on the host.
      - unixreply55 7y ago
        I didn't know of this attack, sounds interesting :) can you explain in a bit more detail how it would work?
        aasasd 7y ago
        Sounds like it works exactly as described by cyphar. The OS trusts permissions that are set on the files, so if you slip it a device ‘file’ writable by anyone then it will let mere users write to the device even if it points to the root filesystem. Devices are denoted simply by numbers on the file inode in the filesystem, it's not difficult to make one that corresponds to the real disk drive.
zmzrr 7y ago
Isn't Veracrypt just a container, like a hard disk? Why should Veracrypt care about what filesystem you store inside of a container, and whatever you do with its permissions?
mehrdadn 7y ago
Can I just point out that this is just one vivid example of why tying setuid permissions to a file is a terrible design to begin with? Permissions should be derived from the execution context at run time. (People might hate me for saying this, but this is one of those design decisions Windows fundamentally gets right.)
- 001spartan 7y ago
  Even Windows gets this wrong at times, with several UAC bypass techniques exposed by auto-elevating binaries. Still, Microsoft has done a great deal of work with the Windows privilege model to prevent things like this, and these issues are steadily being resolved.
  - mehrdadn 7y ago
    https://www.networkworld.com/article/2295224/microsoft--uac-not-a-security-feature.html https://www.networkworld.com/article/2295224/microsoft--uac-...
    - orf 7y ago
      Pasting a random article from 2007 with no other comment is not a great rebuttal of what they said. A _lot_ has changed since 2007.
      - mehrdadn 7y ago
        I'm pretty sure the fact that it's not a security boundary has not changed since 2007. They should've probably marketed it better to clarify this, but that's not a technical issue. It was always a horrible idea to run a malicious program under your credentials relying on UAC to enforce any security. That's never changed.
  - gruez 7y ago
    >with several UAC bypass techniques exposed by auto-elevating binaries According to Raymond Chen, a MSFT employee: >There really are only two [UAC] settings. >* Always notify >* Meh https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105 https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...

by jmakov 7y ago

kuschku 7y ago

Ouch.

bonzini 7y ago

... if you have sudo.

aasasd 7y ago
Where does sudo come in with suid executables? Especially since afaik sudo depends on suid in the first place.
- jlgaddis 7y ago
  One might be granted privileges to mount the filesystem using sudo, but not privileges to run other commands. If the filesystem just mounted has setuid executables, however, the user can then get around their lack of additional sudo privileges by running the setuid executables. Although most people seem to use sudo to allow a user to run anything, that's really not how it was intended to be used.
  - aasasd 7y ago
    That's somewhat different from the Veracrypt case, afaict. And it doesn't seem like this is what bonzini meant by mentioning sudo.
    - bonzini 7y ago
      You still need to gain the privilege to mount filesystems in order to exploit the flaw. So it is a privilege escalation in that you can go from "sudo mount" to a root shell, but it is: 1) not exploitable unless you have sudo 2) pointless if you are authorized to "sudo" any command.
      - jeroenhd 7y ago
        This depends on the setup really; it's possible to limit sudo access to only some commands, like so: %veracryptusers ALL=(root) NOPASSWD:/usr/bin/veracrypt An inexperienced systems administrator might use this to allow some users access to the mount command so that users can use their encrypted USB drives to carry around sensitive data, not realizing that through the intricacies of the Linux filesystem this can lead to privilege escalation. Such a config would normally give you sudo, but not a root shell; allowing certain users to use ping floods to test the network by giving them access to the ping command as root, for example, would not expose much security risks other than flooding the network.
      - aasasd 7y ago
        I see now that you consider sudo necessary for mounting the filesystem, but a) it seems the point in the report is that Truecrypt allowed to grant this ability without using sudo (I guess either via a daemon or just a setuid executable) b) iirc in case of other filesystems you can allow users to mount them without being root—which is how removable devices work in unixes. So this goes around the whole sudo/setuid system and probably might be another option for this feature in Truecrypt too. Lastly, as jeroenhd noted, even with sudo the root privilege can be granted for a script that mounts a volume, or for one particular command. Sudo, by default, doesn't allow the user to add options to the command specified in `sudoers`.

aasasd 7y ago

This surprised me the most―never thought about this before. Aren't all permission-supporting filesystems vulnerable to this if mounting by a user is permitted? I presume filesystems don't go through the files and downgrade root ownership.

unixreply55 7y ago
Yes; that is why it is recommended that untrustworthy drives be mounted with the `nosuid` flag.
- aasasd 7y ago
  Ah, so even though filesystems don't go through files, they still can block the operation of suid. This suggests then that Veracrypt can simply enable the nosuid option when mounting a device.
  - cyphar 7y ago
    And they should also add nodev, to block a similar attack where you add a bunch of block devices with 777 permissions, in an attempt to make the block device "/" is mounted from be readable to a user and thus able to read (and write) any file on the host.
    - unixreply55 7y ago
      I didn't know of this attack, sounds interesting :) can you explain in a bit more detail how it would work?
      - aasasd 7y ago
        Sounds like it works exactly as described by cyphar. The OS trusts permissions that are set on the files, so if you slip it a device ‘file’ writable by anyone then it will let mere users write to the device even if it points to the root filesystem. Devices are denoted simply by numbers on the file inode in the filesystem, it's not difficult to make one that corresponds to the real disk drive.

zmzrr 7y ago

Isn't Veracrypt just a container, like a hard disk? Why should Veracrypt care about what filesystem you store inside of a container, and whatever you do with its permissions?

mehrdadn 7y ago

Can I just point out that this is just one vivid example of why tying setuid permissions to a file is a terrible design to begin with? Permissions should be derived from the execution context at run time. (People might hate me for saying this, but this is one of those design decisions Windows fundamentally gets right.)

001spartan 7y ago
Even Windows gets this wrong at times, with several UAC bypass techniques exposed by auto-elevating binaries. Still, Microsoft has done a great deal of work with the Windows privilege model to prevent things like this, and these issues are steadily being resolved.
- mehrdadn 7y ago
  https://www.networkworld.com/article/2295224/microsoft--uac-not-a-security-feature.html https://www.networkworld.com/article/2295224/microsoft--uac-...
  - orf 7y ago
    Pasting a random article from 2007 with no other comment is not a great rebuttal of what they said. A _lot_ has changed since 2007.
    - mehrdadn 7y ago
      I'm pretty sure the fact that it's not a security boundary has not changed since 2007. They should've probably marketed it better to clarify this, but that's not a technical issue. It was always a horrible idea to run a malicious program under your credentials relying on UAC to enforce any security. That's never changed.
- gruez 7y ago
  >with several UAC bypass techniques exposed by auto-elevating binaries According to Raymond Chen, a MSFT employee: >There really are only two [UAC] settings. >* Always notify >* Meh https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94105 https://devblogs.microsoft.com/oldnewthing/20160816-00/?p=94...