ECryptfs Security Audit • Hacker News Board

Re: ECryptfs Security Audit

#41

Post by simoncion » Sun, Jul 20, 2014, 5:17 PM UTC

mhogomchungu wrote: post #18

wglb wrote: post #17

Earlier quoted context omitted.

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 "/medi…

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?

Re: ECryptfs Security Audit

#42

Post by simoncion » Sun, Jul 20, 2014, 5:18 PM UTC

mhogomchungu wrote: post #40

simoncion wrote: post #35

Earlier quoted context omitted.

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 defaults Use default options: rw, suid, dev, exec, auto, nouser, and async.

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

> 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

Re: ECryptfs Security Audit

#43

Post by mhogomchungu » Sun, Jul 20, 2014, 5:47 PM UTC

simoncion wrote: post #41

mhogomchungu wrote: post #18

Earlier quoted context omitted.

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 "/medi…

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?

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.

Re: ECryptfs Security Audit

#44

Post by simoncion » Sun, Jul 20, 2014, 6:07 PM UTC

mhogomchungu wrote: post #43

simoncion wrote: post #41

Earlier quoted context omitted.

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?

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,t…

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

There's a GUI? Huh. Then, then answer to your question is "I'm not using the TrueCrypt GUI.".

This documentation is pretty representative of what I've been seeing (and what has worked for me) when I've looked in to using TrueCrypt on Linux:

http://www.gentoo-wiki.info/TrueCrypt

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

I was completely unaware of the existence of a TrueCrypt GUI. I understood TrueCrypt to be the block device encryption software that filled the same role as LUKS.

So, you should refine your claim. Rather than saying "TrueCrypt mounts things insecurely." say "There are helper scripts distributed with TrueCrypt that mount things insecurely. They should be fixed.".

> I am aware of discussions around "best practices" when it comes to usage of the mount command.

The thing about Best Practices is that they don't work in all circumstances. If the volume mounting scripts packaged with TrueCrypt get updated, any defaults should be configurable, as there exist folks who need suid binaries in their TC volumes, as well as folks who don't like mounting things in /run . :)

Re: ECryptfs Security Audit

#45

Post by mhogomchungu » Sun, Jul 20, 2014, 7:19 PM UTC

simoncion wrote: post #44

mhogomchungu wrote: post #43

Earlier quoted context omitted.

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,t…

> How are you using TrueCrypt GUI if TrueCrypt is not the part that does the mounting? There's a GUI? Huh. Then, then answer to your question is "I'm not using the TrueCrypt GUI.". This documentation is pretty representative of what I've been seeing (and what has worked for me) when I've looked in to using TrueCrypt on Linux: http://www.gentoo-wiki.info/TrueCrypt > The mounting "script" in this case is TrueCrypt and…

It sounds like you are trying to deflect the fault away from TrueCrypt.I looked at the link you provided and i opened a TrueCrypt volume with this command:

[root@mtz zc]# truecrypt ./rrr.img ../ink -p xxx

[root@mtz zc]#

So i opened it from the command line,i looked at the mounted volume and it was also mounted without "nosuid" option and hence the same problematic behavior is there even when TrueCrypt is used from the terminal.

Even when using the CLI component,TrueCrypt automatically does the mounting and hence its TrueCrypt's fault.

The mounting part is not done by a third party script that just happen to be bundled with TrueCrypt,it is done as a core part of TrueCrypt.The "mount" command is set here[1] and executed here[2]. You can walk up the code path to see where the "nosuid" options should have been set but isnt.

Its kind of hard to follow discussions here so if you want to take this further then respond to my email address at mhogomchungu at Gmail Dot com

[1] https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f...

[2] https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f...

ps: ciphershed is a TrueCrypt fork.You can look up TrueCrypt's original source code if you dont trust the link i gave as i couldnt find easily taggable TrueCrypt source code online

Re: ECryptfs Security Audit

#46

Post by mhogomchungu » Sun, Jul 20, 2014, 7:29 PM UTC

tptacek wrote: post #37

ynniv wrote: post #34

Earlier quoted context omitted.

Regarding authentication it only mentions performance and block failure. It seems that your company does use encrypted DMGs, so are these problem mitigated by having a larger encrypted unit size and reliable data storage?

Think about it. How do you authenticate a block device? Do you: (a) Authenticate the ciphertext of the whole device as a unit? So, any time you update any block on the entire disk, you also need to update the MAC tag? What happens if you do that? Any block corruption occurring anywhere on the device breaks the MAC tag for the entire disk. (b) Authenticate each individual sector? Where do you store the MAC tags? There…

>Authenticate each individual sector? Where do you store the MAC tags? There's an awful lot of sectors on a disk. Also: what does it mean to have a single corrupted sector in a file consisting of many sectors?

openbsd does this with their geli tool[1]. Look at the tool's documentation for the "-a" option.

The authentication stuff are stored on the sector itself. I remember looking at their implementation a while ago but cant seem to be able to dig up the documentation link at the moment.

[1] http://www.freebsd.org/cgi/man.cgi?query=geli&sektion=8&manp...

Re: ECryptfs Security Audit

#47

Post by x1798DE » Sun, Jul 20, 2014, 8:06 PM UTC

simoncion wrote: post #44

mhogomchungu wrote: post #43

Earlier quoted context omitted.

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,t…

> How are you using TrueCrypt GUI if TrueCrypt is not the part that does the mounting? There's a GUI? Huh. Then, then answer to your question is "I'm not using the TrueCrypt GUI.". This documentation is pretty representative of what I've been seeing (and what has worked for me) when I've looked in to using TrueCrypt on Linux: http://www.gentoo-wiki.info/TrueCrypt > The mounting "script" in this case is TrueCrypt and…

>If the volume mounting scripts packaged with TrueCrypt get updated

To be clear, it would be a serious coup if this happened in TrueCrypt itself. The developers have made it very clear that TrueCrypt is now an abandoned project. They've expressed a preference that no one fork it, but there will almost certainly be a "pseudo-fork" programmed using TC as reference code.

I suppose it's fine to use "Updating TrueCrypt" as a sort of shorthand for "change this in the pseudo-fork", I just wanted to make it clear that during the gap between TrueCrypt and whatever its successor will be, it's best to focus on mitigation strategies for vulnerabilities.

Re: ECryptfs Security Audit

#48

Post by simoncion » Sun, Jul 20, 2014, 9:46 PM UTC

mhogomchungu wrote: post #45

simoncion wrote: post #44

Earlier quoted context omitted.

> How are you using TrueCrypt GUI if TrueCrypt is not the part that does the mounting? There's a GUI? Huh. Then, then answer to your question is "I'm not using the TrueCrypt GUI.". This documentation is pretty representative of what I've been seeing (and what has worked for me) when I've looked in to using TrueCrypt on Linux: http://www.gentoo-wiki.info/TrueCrypt > The mounting "script" in this case is TrueCrypt and…

It sounds like you are trying to deflect the fault away from TrueCrypt.I looked at the link you provided and i opened a TrueCrypt volume with this command: [root@mtz zc]# truecrypt ./rrr.img ../ink -p xxx [root@mtz zc]# So i opened it from the command line,i looked at the mounted volume and it was also mounted without "nosuid" option and hence the same problematic behavior is there even when TrueCrypt is used from th…

There's a reason why I've not included my email address in my HN profile. I'll keep the discussion here. :)

So, if you check the truecrypt manpage [0] (or the code in that GH repo that you linked to) you'll see the presence of the --mount-options option. This allows you to pass along any and all options to mount(8) that you wish to pass along... including nosuid.

The problem you're describing isn't in TrueCrypt the crypto software, it's in its mount(8) wrapper code. TC behaves as block device encryption software, with a wrapper around mount(8) to handle volume mounting, if you want to also mount those volumes. The wrapper around mount behaves exactly as it should... which is that its defaults are the same defaults as mount, and it provides you options (through --mount-options) to change those defaults, by passing those options to mount.

Any other behavior would violate expectations and, thus be grossly incorrect. If you're concerned about others passing you a backdoor flagged with the suid bit, then the TrueCrypt authors gave you a method to mount all TC volumes with the nosuid option set by default. (And, if you're really concerned about the scenario that you outlined, you need a wrapper around mount, anyway, as ALL filesystems that support suid-flagged binaries are "vulnerable" to this "attack".)

TC doesn't need to be changed because of this. :)

[0] http://www.irongeek.com/i.php?page=backtrack-3-man/truecrypt

Re: ECryptfs Security Audit

#49

Post by bignaj » Sun, Jul 20, 2014, 9:50 PM UTC

Dylan16807 wrote: post #30

bignaj wrote: post #3

Earlier quoted context omitted.

Well, TrueCrypt (controversially) recommended BitLocker... that seems to be one of the few options left. Disclaimer: I work for Microsoft in a non-related division but I feel like if it's good enough to protect enterprise customers' secrets it's good enough for my personal use outside of work. You are free to use whatever you like, of course. The HN neckbeard illuminati will likely disagree with me, already aware of…

That disclaimer really detracts from your post. But on topic, BitLocker is only suitable for enterprise because it's simply unavailable for home versions.

I agree, but I feel like it's only fair to report any potential conflict of interest (come from a research background where this is standard). You are also incorrect: Bitlocker is not only available for enterprise versions. See the other reply to your comment :)

Re: ECryptfs Security Audit

#50

Post by simoncion » Sun, Jul 20, 2014, 9:52 PM UTC

x1798DE wrote: post #47

simoncion wrote: post #44

Earlier quoted context omitted.

> How are you using TrueCrypt GUI if TrueCrypt is not the part that does the mounting? There's a GUI? Huh. Then, then answer to your question is "I'm not using the TrueCrypt GUI.". This documentation is pretty representative of what I've been seeing (and what has worked for me) when I've looked in to using TrueCrypt on Linux: http://www.gentoo-wiki.info/TrueCrypt > The mounting "script" in this case is TrueCrypt and…

> If the volume mounting scripts packaged with TrueCrypt get updated To be clear, it would be a serious coup if this happened in TrueCrypt itself. The developers have made it very clear that TrueCrypt is now an abandoned project. They've expressed a preference that no one fork it, but there will almost certainly be a "pseudo-fork" programmed using TC as reference code. I suppose it's fine to use "Updating TrueCrypt"…

Yeah. TC development has been halted. I'm aware of that. :)

The issue that the grand-parent describes isn't an issue. TC passes along mount options to mount(8). Its mount defaults are the same as mount's defaults, and TC provides a mechanism to pass along other user-specified mount options directly to mount. It makes just as much sense to complain to the TC authors about this issue as it does to complain to Ted Ts'o about the exact same "issue" in ext4, or Chris Mason about the same in Btrfs. :)