[mhogomchungu]

TrueCrypt in linux has a serious security issue discussed below and i hope you guys will address this.

TrueCrypt has a serious security bug that allows a person who can mount TrueCrypt volumes to get root shell or run any command as root user because it mount its volumes with "suid" option instead of "nosuid" option.

You can get the below program to test locally if you have a linux box around.

http://pastebin.com/vT4G7nU0

[simoncion]

> 4. set the binary to have 4755 permissions with owner as root:root.

If you can do this, you already have root access. If you have root access, then you don't need dirty tricks to get root access.

Additionally, in the three minutes that I spent searching, I found a bunch of evidence that indicated that TrueCrypt volumes mounted through FUSE are mounted with the nosuid option. (Ferinstance, search for 'nosuid' here: http://www.reddit.com/r/archlinux/comments/1fcwvr/truecrypt_... )

[mhogomchungu]

Reads the instructions again

At step 4,you create the volume on the computer you have root access(a home computer for example),copy the program and set up necessary permission on the program

At step 5,you take the "hot" volume to another computer where you do not have root access to(like a friend's computer).On this friend computer,you open the "hot" volume and then run the suid-root program to gain root shell or run any other root command your prefer.

In a nutshell,if you are on linux and you have TrueCrypt installed,give me your computer to open my TrueCrypt volume and i can get root shell in seconds.No kidding.

The link i provided gave source code to test the exploit,if you cant or prefer not to,the check below link that speaks of the same exploit

http://vinicius777.github.io/blog/2014/07/14/truecrypt-privi...

[simoncion]

I cannot repro. See this transcript:

http://pastebin.com/y958QtWh

By the way:

  $ man mount
  MOUNT(8)                     System Administration                    MOUNT(8)

  NAME
       mount - mount a filesystem

  SYNOPSIS
  <snip>
       defaults
              Use default options: rw, suid, dev, exec, auto, nouser, and async.
  <snip>

[mhogomchungu]

Its because you overrode the default option of "suid" with your "nosuid" when mounting.TrueCrypt does not do this and that is where the problem is.

To reproduce the problem,use TrueCrypt with its default mount options,or do your mounting with mount's default options.

The fundamental problem is a bad usage of mount command that comes from usage of mount's default options.You cant reproduce the problem because you changed a bad default option to a good one.

[simoncion]

> The fundamental problem is ... mount's default options.

This is exactly my point. You might as well complain to Ted Ts'o about the same vulnerability in ext4. Please do reply to my comment here: https://news.ycombinator.com/item?id=8060884

[wglb]

How is this different than creating a disk with appropriate properties and handing it to a gullible system operator to mount the physical device?

[mhogomchungu]

Its not.

A user provided volume/device should always be mounted with "nosuid,nodev" options,some people will add "noexec" into the mix but i find it not to be very useful.

Most "sane" mount front ends will also not mount any arbitrary file system on these user provided volumes/devices.They will only mount file systems they explicitly allow and file systems that are already known by the system ie file systems whose modules are already loaded.This is done to prevent misuse of mount to load kernel modules that are not already loaded.

The problem is with what options were used with mount command and TrueCrypt uses bad options.Here,TrueCrypt is used not for its encryption feature,but for its bad mount command usage.Any other tool with the same bad usage will do in carrying out the exploit.

[wglb]

So perhaps TrueCrypt in linux has a serious security issue should be changed to read Linux has a serious security issue

Doesn't sound particular to TrueCrypt.

I remember fielding a support call from a customer running Coherent on the Commodore Z8000 system who fabricated a floppy with pretty much the same properties--used a user-space program to create a floppy with setuid and then mounted it.

Doesn't sound like TrueCrypt's problem.

[mhogomchungu]

There are "standard practices" when it comes to usage of the mount tool and TrueCrypt does not follow them and its inability to follow them is what leads to this privilege escalation.

Another "standard practice" TrueCrypt is not following is its creation of the mount point with 0777 permissions at "/media",a directory that is world readable.A "standard practice" is to have mount points at "/run/media/$USER" or "/media/$USER" or anywhere else where only the owner of the mount point has access to it.This is another security issue that need to be addressed.

[simoncion]

Everywhere I look to see how to use TrueCrypt on Linux, I see it being used as just another encrypted block device. This strongly indicates that any policy issues that you're bringing up aren't the fault of TrueCrypt, but rather are issues with whatever mount scripts you're using.

Can you point me to some documentation that would give me cause to believe otherwise?

[mhogomchungu]

What steps are involved when mounting a TrueCrypt volume?

This is what happens when you mount a TrueCrypt volume using their GUI application in linux.

1. A TrueCrypt volume is unlocked by TrueCrypt.

2. The unlocked volume is mounted by TrueCrypt.

The mounting "script" in this case is TrueCrypt and hence it is TrueCrypt's fault.

If you unlock the volume using TrueCrypt and then mount the unlocked volume using udisks,then it would be udisks' fault.

If you unlock the volume using TrueCrypt and then mount the volume yourself,then it will be your fault.

The fault is in the person who is doing the mounting and in TrueCrypt's GUI application case,TrueCrypt is the one who is doing the mounting and hence its TrueCrypt's fault.

How are you using TrueCrypt GUI if TrueCrypt is not the part that does the mounting?

I am not aware of any documentations but i am aware of discussions around "best practices" when it comes to usage of the mount command.

[tptacek]

I'm only involved in the cryptography stuff.