German BSI withholds Truecrypt security report

Post by gruez » Mon, Dec 16, 2019, 9:48 PM UTC

001spartan wrote: post #55

mehrdadn wrote: post #52

Earlier quoted context omitted.

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

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.

Post by gruez » Mon, Dec 16, 2019, 9:52 PM UTC

aasasd wrote: post #28

jmakov wrote: post #13

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

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.

Post by gruez » Mon, Dec 16, 2019, 10:33 PM UTC

cantrevealname wrote: post #62

The casual user stumbling on this article is going to think that TrueCrypt or VeraCrypt has been broken. There’s a big difference between attacks on a live system when a volume is being used, versus cases in which an encrypted volume is lost, stolen, or copied. It needs to be firmly said that there is still no known way to recover plaintext from an unmounted TrueCrypt or VeraCrypt volume on a powered-off system witho…

Post by saagarjha » Mon, Dec 16, 2019, 10:47 PM UTC

mehrdadn wrote: post #52

jmakov wrote: post #13

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

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

Post by bonzini » Mon, Dec 16, 2019, 10:54 PM UTC

aasasd wrote: post #45

jlgaddis wrote: post #42

Earlier quoted context omitted.

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.

That's somewhat different from the Veracrypt case, afaict. And it doesn't seem like this is what bonzini meant by mentioning sudo.