Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECryptfs Security Audit

defuse.ca

Post reply on HN
Print view View original

11–20 of 66 posts

Re: ECryptfs Security Audit

#11

Post by mhogomchungu »

tptacek wrote: post #7
x1798DE wrote: post #6

Earlier quoted context omitted.

> What would people recommend these days seeing as TrueCrypt is likely to be compromised and ecryptfs might not be as secure as it could be? Just to push back on this a bit, I don't think it's particularly likely that TrueCrypt is in any way compromised. It's been stable software for quite some time now, it's open source, and there have been no identified flaws with it. The main problem with TrueCrypt is that it may…

I'm involved in the TC audit, and zero of the people I know that are working with the TC audit believe that it's compromised.

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

Re: ECryptfs Security Audit

#12

Post by simoncion »

mhogomchungu wrote: post #11
tptacek wrote: post #7

Earlier quoted context omitted.

I'm involved in the TC audit, and zero of the people I know that are working with the TC audit believe that it's compromised.

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/vT4…

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

Re: ECryptfs Security Audit

#13

Post by wglb »

mhogomchungu wrote: post #11
tptacek wrote: post #7

Earlier quoted context omitted.

I'm involved in the TC audit, and zero of the people I know that are working with the TC audit believe that it's compromised.

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/vT4…

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

Re: ECryptfs Security Audit

#14

Post by mhogomchungu »

simoncion wrote: post #12
mhogomchungu wrote: post #11

Earlier quoted context omitted.

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/vT4…

> 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:…

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

Re: ECryptfs Security Audit

#15

Post by mhogomchungu »

wglb wrote: post #13
mhogomchungu wrote: post #11

Earlier quoted context omitted.

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/vT4…

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

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.

Re: ECryptfs Security Audit

#16

Post by wyager »

tptacek wrote: post #4
hadoukenio wrote: post #2

I chose eryptfs over TrueCrypt because I wasn't happy with using encryption software written by an anonymous developer. Was this a naive decision or do others feel the same? The audit linked says that it ecryptfs might not have been designed/written by a cryptographer. What would people recommend these days seeing as TrueCrypt is likely to be compromised and ecryptfs might not be as secure as it could be?

EcryptFS and Truecrypt are very different systems. Truecrypt is simulated hardware encryption. It creates a virtual encrypted hard disk, which your operating system can more or less treat like an ordinary hard disk, but for the kernel hooks Truecrypt adds to lock and unlock the disk. EcryptFS is an encrypted filesystem. Unlike Truecrypt, which encrypts individual disk blocks, systems like EcryptFS encrypt and decrypt…

>All else being equal, you'd prefer an encrypted filesystem to a simulated encrypted hard disk.

I disagree for these reasons:

1. This decreases composability. With encrypted filesystems, I can't mix and match filesystems and cryptosystems to suit my needs. There is no reason they need to be convolved.

2. This increases complexity. Now, the person writing the software has to be an expert in both filesystems and cryptosystems if they want to do a good job. There is more room for error. (You might say it violates the UNIX philosophy of "do one thing and do it well".)

3. This leaks information to an attacker. They know the layout of my files even without my password. I'm more comfortable with absolutely everything looking like a giant monolithic block of random data.

Re: ECryptfs Security Audit

#17

Post by wglb »

mhogomchungu wrote: post #15
wglb wrote: post #13

Earlier quoted context omitted.

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

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 mo…

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.

Re: ECryptfs Security Audit

#18

Post by mhogomchungu »

wglb wrote: post #17
mhogomchungu wrote: post #15

Earlier quoted context omitted.

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 mo…

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 True…

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.

Re: ECryptfs Security Audit

#19

Post by objectivefs »

tptacek wrote: post #4
hadoukenio wrote: post #2

I chose eryptfs over TrueCrypt because I wasn't happy with using encryption software written by an anonymous developer. Was this a naive decision or do others feel the same? The audit linked says that it ecryptfs might not have been designed/written by a cryptographer. What would people recommend these days seeing as TrueCrypt is likely to be compromised and ecryptfs might not be as secure as it could be?

EcryptFS and Truecrypt are very different systems. Truecrypt is simulated hardware encryption. It creates a virtual encrypted hard disk, which your operating system can more or less treat like an ordinary hard disk, but for the kernel hooks Truecrypt adds to lock and unlock the disk. EcryptFS is an encrypted filesystem. Unlike Truecrypt, which encrypts individual disk blocks, systems like EcryptFS encrypt and decrypt…

For laptops it might be easier to avoid storing any of your sensitive data to disk.

Use a non-local encrypted filesystem per project to get the isolation and to avoid your local storage. Mount the project filesystem when needed, unmount it when done, and when not in use it is simply inaccessible to the laptop.

While any encrypted filesystem not stored on your laptop would work for this, ours[1] makes this workflow very easy.

[1] https://objectivefs.com

Re: ECryptfs Security Audit

#20

Post by tptacek »

mhogomchungu wrote: post #11
tptacek wrote: post #7

Earlier quoted context omitted.

I'm involved in the TC audit, and zero of the people I know that are working with the TC audit believe that it's compromised.

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/vT4…

I'm only involved in the cryptography stuff.
Post reply on HN