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

31–40 of 66 posts

Re: ECryptfs Security Audit

#31

Post by ynniv »

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…

block crypto is typically not authenticated

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.

Re: ECryptfs Security Audit

#32

Post by tptacek »

ynniv wrote: post #31
tptacek wrote: post #4

Earlier quoted context omitted.

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…

block crypto is typically not authenticated 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.

No, it's not simple oversight. Here's my best stab at an explanation:

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.

Re: ECryptfs Security Audit

#33

Post by eli »

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.

No, it's available on the "Ultimate" edition of windows too, which is for home use. Many higher-end Windows machines come with it already installed.

Re: ECryptfs Security Audit

#34

Post by ynniv »

tptacek wrote: post #32
ynniv wrote: post #31

Earlier quoted context omitted.

block crypto is typically not authenticated 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.

No, it's not simple oversight. Here's my best stab at an explanation: 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 ha…

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?

Re: ECryptfs Security Audit

#35

Post by simoncion »

mhogomchungu wrote: post #14
simoncion wrote: post #12

Earlier quoted context omitted.

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

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.

Re: ECryptfs Security Audit

#36

Post by wyager »

tptacek wrote: post #21
wyager wrote: post #16

Earlier quoted context omitted.

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

There's nothing I can say in response to this comment that I haven't already said upthread and here: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Thanks for the link. Those are some very valid points.

Re: ECryptfs Security Audit

#37

Post by tptacek »

ynniv wrote: post #34
tptacek wrote: post #32

Earlier quoted context omitted.

No, it's not simple oversight. Here's my best stab at an explanation: 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 ha…

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

Re: ECryptfs Security Audit

#38

Post by [deleted] »

wyager wrote: post #36
tptacek wrote: post #21

Earlier quoted context omitted.

There's nothing I can say in response to this comment that I haven't already said upthread and here: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Thanks for the link. Those are some very valid points.

[deleted]

Re: ECryptfs Security Audit

#39

Post by tptacek »

wyager wrote: post #36
tptacek wrote: post #21

Earlier quoted context omitted.

There's nothing I can say in response to this comment that I haven't already said upthread and here: http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Thanks for the link. Those are some very valid points.

Of course, there's some validity to the "composability" point, which is why we use both full-disk encryption and encryption at the filesystem layer. I don't think enabling full-disk encryption is a bad thing. Having full-disk encryption is what allows me not to panic if I leave my laptop in the unlocked back seat of my car; I don't have to worry about what state the filesystem was in, because the whole disk is locked.

Re: ECryptfs Security Audit

#40

Post by mhogomchungu »

simoncion wrote: post #35
mhogomchungu wrote: post #14

Earlier quoted context omitted.

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…

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 changed a bad default option to a good one.

Post reply on HN