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 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: [E] http://code.google.com/p/encfs/source/detail?r=59 Asked Valient to confirm yet, [E] is the proper patch for issue (2) / the watermarking attack /. * for issue (3) -- not sure about patch status. CVE Request: [F] http://www.openwall.com/lists/oss-security/2010/09/05/3
Created attachment 443181 [details] Local text copy of EncFS report from Full Disclosure
Created attachment 443182 [details] Local copy of public proof of concept archive provided by Micha Riser in that Full Disclosure post
Issue "(2) Watermarking attack" affects the versions of the fuse-encfs package, as shipped with Fedora release of 12 and 13. Please fix (once patch [E] was confirmed to be the proper one to address this issue).
Reply from Valient Gough regarding the patch in question (http://www.openwall.com/lists/oss-security/2010/09/06/1): 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 (see http://www.openwall.com/lists/oss-security/2010/09/05/3 for slightly changed reference points).
The following CVE identifiers have been assigned to these issues: 1, CVE-2010-3073 encfs Only 32 bit of file IV used 2, CVE-2010-3074 encfs Watermarking attack 3, CVE-2010-3075 encfs Last block with single byte is insecure
Hello. Was this bug addressed properly? I found following lines in fuse-encfs-1.7.4-6.fc17.src.rpm's changelog: * Sun Sep 5 14:00:00 2010 Peter Lemenkov <lemenkov> - 1.7.1-1 - Fixed three security flaws (see rhbz #630460) - Cleaned up spec-file a little
(In reply to comment #6) > Hello. Was this bug addressed properly? > > I found following lines in fuse-encfs-1.7.4-6.fc17.src.rpm's changelog: > * Sun Sep 5 14:00:00 2010 Peter Lemenkov <lemenkov> - 1.7.1-1 > - Fixed three security flaws (see rhbz #630460) > - Cleaned up spec-file a little Yes, it was. I built the very latest encfs version which is claimed to contain all the necessary fixes.