Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <B4EF424B-CFF6-4745-879B-9473EB0FFDC3@gmail.com>
Date: Sun, 5 Sep 2010 21:47:00 -0700
From: Valient Gough <valient@...il.com>
To: oss-security <oss-security@...ts.openwall.com>
Cc: "Steven M. Christey" <coley@...us.mitre.org>,
 Micha Riser <micha@...world.org>
Subject: Re: CVE Request -- EncFS / fuse-encfs [three ids] -- Multiple Vulnerabilities in EncFS


On Sep 5, 2010, at 11:33 AM, Jan Lieskovsky wrote:

> Hello Steve, vendors,
> 
>  Micha Riser reported:
>  [A] http://archives.neohapsis.com/archives/fulldisclosure/2010-08/0316.html
> 
> three security flaws in EncFS encrypted filesystem (more from [A]):
> 
> "A security analysis of EncFS has revealed multiple vulnerabilities:
> (1) Only 32 bit of file IV used
> (2) Watermarking attack
> (3) Last block with single byte is insecure"
> 
> References:
>  [B] http://www.arg0.net/encfs
>  [C] http://bugs.gentoo.org/show_bug.cgi?id=335938
>  [D] http://archives.neohapsis.com/archives/fulldisclosure/2010-08/att-0316/watermark-attack-encfs.tar.gz
>  [E] https://bugzilla.redhat.com/show_bug.cgi?id=630460
> 
> 
> Solutions / patches information:
> ================================
> 
> * for issue (1) -- seems it wasn't fixed / isn't possible to
>  fix without breaking backward compatibility. More from [B]:
> 
>  "The old IV setup is kept for backwards compatibility."
> 
> * for issue (2) -- EncFS upstream has released a fix for the issue:
>  [F] http://code.google.com/p/encfs/source/detail?r=59
> 
> Valient, could you please confirm, the above referenced [F] patch,
> is the correct one to address the watermarking attack issue?
> 
> * for issue (3) -- not sure about patch status (included in [F] too?)
> 

Jan,

Yes, the patch referenced in [F],  specifically changes to SSL_Cipher.cpp, were made in response to issues (1) & (2).  These are not backward compatible, and so only apply to new filesystems.

Issue (3) is not directly addressed.  A workaround is to enable per-block MAC headers, or per-block random bytes.  A patch going into 1.7.2 allows per-block random bytes to be configured independently of MAC headers.  It would be possible to change the default settings such that per-block random bytes are always used.

Adding new encryption modes is not planned for encfs 1.x.

regards,
Valient



Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.