ECryptfs Security Audit(defuse.ca) |
ECryptfs Security Audit(defuse.ca) |
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?
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 whole files.
All else being equal, you'd prefer an encrypted filesystem to a simulated encrypted hard disk. Some of the reasons are technical: the crypto involved in encrypting a block device is crappier than the crypto involved in protecting a file (most notably, block crypto is typically not authenticated). But at a higher level, the reason is that you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.
All things are not equal though, and to select EcryptFS over Truecrypt, you also have to select EcryptFS's design and implementation over Truecrypt's. Truecrypt's design is simple and has been looked at more carefully than EcryptFS's. On the other hand, Truecrypt is an XTS cryptosystem, which isn't great. I would have a hard time making a recommendation between the two.
It's more important that you understand the limitations of transparent disk encryption. Unless you are pretty regularly telling your crypto software that it's OK to unlock a given file or disk or whatever, then it's probably "always on", and your keys are always resident in memory, and your files are more or less always exposed to malware. Malware is a much scarier threat (for most people) than police raids.
If you're interested: we work in a pretty high-risk environment (we handle a lot of hazmat). Our general crypto regime at Matasano is:
* Everyone uses Filevault2's native XTS disk encryption (along with some fiddly rules for what state your machine needs to be in if it's in your bag).
* Everyone uses OS X encrypted DMGs (I don't remember what the block crypto design for DMGs is, but you can check out John the Ripper if you're curious) to isolate different projects; we audit machines to make sure keys aren't in the keyring.
* Everyone uses PGP for email and to encrypt specific files.
If this sounds like a pain in the ass, be aware that this is pretty close to the minimum viable amount of security you can be providing a mobile device; if you're skipping one of these steps, you should know why.
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.
I should have explained my reasoning for originally choosing ecryptfs. I find it really convenient doing a backup of ecryptfs' cipher-text. Since it's simple files, an rsync will do. If I wanted to backup virtual encrypted disks, I would first have to mount source and destination to do an rsync, or painstakingly do an entire dd without the mount... maybe I'm just doing it wrong?
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.
Is this simple oversight?
you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.
Doesn't this leak information? An attacker knows very little about an opaque block, but may be able to use file length and modification order to some advantage.
It has the extreme disadvantage that I can't mount my disk on anything except windows. Which is a no-go given that I mostly live in Linux and most of my colleagues do a lot of work with MacOS. We all have Windows machines for the bureaucratic stuff we must do (word documents, excel, various internal web portals that require IE or some sort of ActiveX plugin). The things is: when it comes to closed source companies, Microsoft is one that I am willing to accept that they have sound engineering and release policies. But they refuse to explain how it works, so we can't inter-operate and we have to do something else.
(Which for me means that I use a FIPS certified hardware encrypted USB drive with a built in keypad that you use to enter a pin, but for everyone else it basically means they don't bother and just use stupid unencrypted FAT drives and don't care if they "get caught". Or they try to use the awful Box sync shit IT is currently trying to foist on us)
But on topic, BitLocker is only suitable for enterprise because it's simply unavailable for home versions.
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 be nearing the end of its useful life as filesystem technology changes and TrueCrypt is not updated along with it (this has already happened with GPT/UEFI and TrueCrypt's full-disk encryption). If TrueCrypt will work for you, at the moment you don't really have to worry that it's been compromised or worry about "lack of support" (note it hadn't been updated for over two years before the abrupt departure of the anonymous devs).
It's quite possible that you won't even run into any compatibility issues in the future, as future encryption tools will likely offer support for TrueCrypt volumes - once the phase II (crypto) audit is complete, assuming no major flaws are found, it will be a vetted, open technology, so it'd be a no-brainer to write an implementation based on it.
Separate vaults are useful if you have multiple clients, say, and you are doing pen tests. While you are working on one, the others are not unlocked.
https://github.com/Aorimn/dislockerUltimate is a weird expensive combined edition that doesn't even exist for Windows 8. I didn't think I had to specifically exclude it, but I definitely don't accept it as making BitLocker available for 'home versions'
You use the build-in disk image encrypted volumes (AES-128/256 IIRC), or some proprietary software? Do you have a standard policy (e.g. FileVault) or no?
http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
Regarding information leakage: both schemes leak some degree of information (for reasons I get into in that post, XTS is deterministic). But because encrypted filesystems don't have to respect strict block boundaries, they can do a variety of things to limit or eliminate leakage. It's much harder for block device crypto to solve this problem.
Naive encrypted filesystems don't, of course. Like I said, I'd have a hard time making a recommendation between Truecrypt and EcryptFS.
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'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?
(c) ???
Of course, the answer is that full-disk encryption tools (ie simulated encrypted disks, like Truecrypt) don't authenticate. There's no good place to store the tags and no good units of data to authenticate.
What does it mean that encrypted disk sectors aren't authenticated? Well, it means two things:
(i) Attackers can perform targeted rewrites of data on the disk, typically at a full-sector level; in practice, this means that they can randomize any sector of the disk, and the encryption software can't know that the now-random data isn't real data, nor can the operating system. By aiming these random blocks at trusted metadata or executable binary code, attackers can potentially turn this ability into a much more serious attack.
(ii) Because the encryption software must trust the outcome of decryption, even when attackers tamper with data to make its output random, attackers gain the ability to feed chosen ciphertext into the encryption software. This sounds like an academic concern, but it's the basis for many of cryptosystem attack classes we've learned about in the past decade, most notably the padding oracles.
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.
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_... )
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...
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.
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...
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.
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.
Can you point me to some documentation that would give me cause to believe otherwise?
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>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.
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
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.
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 . :)
[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
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.
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. :)
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
Now,how exactly can you set up TrueCrypt so that a student could not use it to get root shell as i specified?.
Simple answer,you cant.
Yes,TrueCrypt gives you an option to pass the "nosuid" option.But thats like having a system that requires a password but gives you an option to not provide it with the default behavior being the option of not providing it.
The student who will sit on that computer lab with a TrueCrypt GUI window open will be the one who gets to decide if they want to set the option or not and with the option being off by default,the student will just execute the exploit without changing anything.
I should also say that i am mhogomchungu,the founder of zuluCrypt[1] that does block device encryption and also general purpose mounting with zuluMount,a tool that ships with zuluCrypt and hence i have looked at this problem very closely and for years now and i have closely followed how other FOSS projects reason with problems associated with mount command usage and their implementations to work around the problems.There are also other bunch or wrongs that TrueCrypt is doing and i know this from looking at how things are implemented "from inside" and not how they appear from outside.
Somebody using zuluCrypt to gain root shell and i will take full responsibility for it,somebody use udisks to get root shell access and i will place responsibility fully on udisks and i am fairly certain they will do the same.
Two answers, both simple:
1) You could ask that question about any FS that Linux supports that supports suid binaries. This issue isn't unique to TrueCrypt. This was mentioned upthread by wglb [0], but you brushed him aside with talk of "standard practice".
2) Rename '/bin/mount' to '/bin/mount-real'. Replace /bin/mount with a shell script that checks the desired mountpoint against the mountpoints listed in /etc/fstab (and others, like autofs). If the desired mountpoint is not listed there, add nosuid to the options passed along to /bin/mount-real. Do tell me what I missed here, I only spent two minutes thinking through it.
It is not unique to TrueCrypt.It is an issue that arise when a front end to "mount" command BADLY uses it and TrueCrypt BADLY uses "mount" command in a way that leads to privilege escalation as i explained it.
Any front end to "mount" command that uses the command in a BAD way will end up with the same BAD behavior.We are talking about TrueCrypt here and its BAD usage of "mount" command.
If you can use zuluCrypt and gain root shell,i will take responsibility for it and fix the problem.There will be no finger pointing of who is at fault,you got the elevated privileges through my tool and that makes it my problem and it should be me who should fix it.
The elevated privileges were acquired through TrueCrypt and hence its TrueCrypt's fault and TrueCrypt need to fix it or users of TrueCrypt should be made aware of it so that they can guard themselves against.It should be noted that you failed to show they could do so.It should be noted that i mentioned this initially so that those who do TrueCrypt code review will know of it and maybe do something about it.The talk of "its not unique to TrueCrypt" seems to me like an attempt to deflect attention away from the problem as it exists in TrueCrypt.
I did not brush him off,i tried to explain something,maybe you missed it.Let me say it differently.If ext4 has a mount option "--foo" and the "standard practice" is for normal users not to be allowed to use this mount option and you have a mounting tool that chooses to ignore this standard practice and hence a normal user mounts the volume with the mount option and gain root privileges,then the problem will be on your mounting tool and it will be your fault and it will be you who will need to fix the problem.The problem will not be on ext4 file system or on this option.You cause the problem,its your fault.What he tried to do is place fault on linux and make it sound like TrueCrypt is a victim of it and i attempted to place the blame back on TrueCrypt by showing the fault lying in TrueCrypt's lack of following "best practices".I hope that makes sense.
When it comes to mounting in linux,things are done in a specific way and if you create a mounting tool and do things differently,then any breakage or privilege escalations will be on you and it will be your fault.Trying to deflect the problem will only make things bad for you and people will loose trust in your tool.
I am writing this as a person who has spent years thinking about these stuff and write code that implements them and not somebody who has spent minutes thinking about them.
About your second point.What you missed is that you can not do that kind of modification on other people's machines.Making this kind of changes behind user's back should be an offense deserving of being shot.
If you ship some software that wraps mount(8), it is expected that that something's defaults will be the same as mount(8)'s defaults. It is also expected that that mount wrapper will permit the user to pass along additional options to mount, so that one can override mount's defaults. Anything else violates expectations and, thus, is incorrect. In other words, TrueCrypt's mount wrapper does things correctly.
Every competent Linux system administrator knows that mount's default options enable setuid binaries, knows the risks of setuid binaries, knows how to pass nosuid to mount, and knows how to write his own wrapper to mount to be pretty sure that only volumes he wishes can be mounted suid. If one is a Linux system administrator, and one does not know these things, then one is, by definition, an incompetent Linux system administrator. Linux is a power tool, not a pair of safety scissors.
I notice that you didn't evaluate either answer to your challenge. Does my second answer contain an error? Why do you have no remark for my first answer?
Let me repeat.
It is a BAD idea to mount a user provided volume with "suid" options. Any mount tool that does this is using mount tool in a BAD way.I think i have said this already.
TrueCrypt is mounting a user provided volume with "suid" option and hence TrueCrypt is using mount command in a BAD way.I think i have already said this.
This is not a problem unique to TrueCrypt.It is a problem that will exist on any mount tool that uses mount command in a BAD way.I think i have already said this too.
Your second answer will solve the problem.It will solve it by filtering out a BAD TrueCrypt mount option.Another way to solve the problem is to modify TrueCrypt source code and add the good option.The modification of the source code is an appropriate approach since it will solve the problem on everybody.
Your second answer will also solve the problem while you insist that "there is no problem to solve as TrueCrypt is doing things the correct way".This kind of talk is commonly known as "double speak".
[1]AFAIK, based on the video, and knowing that it doesn't require admin on windows
1) Use FUSE's ability to (as a non-root user) mount user-readable devices in a user-owned directory.
2) Do as Docker does and talk to over a socket to a daemon running as root.
From what I've seen the official TrueCrypt software does neither of these things. What video are you talking about? Perhaps I missed something?
On Windows, it's not uncommon for an unprivileged process to talk to a root-equivalent Service to perform privileged operations.
So this isn't a security flaw, this is a feature request for non-root mounting.
Except you can already use FUSE so I'm not sure what the complaint is at all. Don't let people run commands as root that weren't designed for it.
Sorry about the noise.
[1] http://vinicius777.github.io/blog/2014/07/14/truecrypt-privi...
You need root privileges to gain access to kernel cryto and other kernel managed resources.
For a project to be usable to normal users,it need to be assessable to normal users and hence it need to walk a fine line between being privileged and being not privileged as it need to exist on both side of the fence.
As far as TrueCrypt is concerned,any person who sets up TrueCrypt for somebody else to use end up setting up passwordless sudo for it and this opens up the discussed problem.It is a security issue in a sense that TrueCrypt does not take into account its privileged position when it interfaces with mount command.You can nitpick on the passwordless sudo part but one way or the other,TrueCrypt expect to be run privileged and sudo is the easiest path but pick any other method you prefer.
FUSE will give you a workaround as far as mounting is concerned but you will still need root privileges when invoking kernel crypto or other kernel managed infrastructure. FUSE also solves a mounting problem but a different one.
There are 3 different "techniques" that can be used to allow a normal user to do mounting operations and i discussed them here[1] as the first FAQ entry.
This will be a security issue if it happened to udisks or anybody else i know.Maybe linux users of TrueCrypt are a completely different audience when it comes to this kind of privilege separation issues.
This is a feature request, not a security flaw. It's a pretty glaring gap that should be filled, but it's not a mistake.
Start TrueCrypt GUI from a normal user account and TrueCrypt will attempt to self elevate internally using a functional sudo setup.This shows a deliberate attempt by TrueCrypt to be usable by normal users.It just leave it up to the user to setup sudo for it.
Setup sudo to require a password and TrueCrypt will get stuck on its password prompt(bug) and hence passwordless sudo setup will be the only way to go when setting up TrueCrypt to be used by normal users or,alternatively,starting up TrueCrypt from root's account for normal users(not very practical/convenient).
With both ways,the discussed problem will be there.