Bug#736066: Allow encfs into jessie?
On Thu, Oct 30, 2014 at 09:19:37PM +0100, Eduard Bloch wrote: > severity 736066 important > thanks > > Dear Security Team, > > FYI, as discussed in this bug report, I am lowering the severity of this > bug because of not considering this a general security problem. It's > only an issue in specific scenarios which are sufficiently explained > now. According to https://github.com/vgough/encfs/issues/14 this seems closed in 1.8.1? Please confirm and close the bug as needed. Cheers, Moritz
Bug#736066: Allow encfs into jessie?
severity 736066 important thanks Dear Security Team, FYI, as discussed in this bug report, I am lowering the severity of this bug because of not considering this a general security problem. It's only an issue in specific scenarios which are sufficiently explained now. Regards, Eduard. * Eduard Bloch [Thu, Sep 11 2014, 04:55:14PM]: > Hallo, > * Jan Niehusmann [Thu, Sep 11 2014, 12:12:08PM]: > > > The bug report is about security issues, but these are not security > > issues of the software (as in: you can somehow hack into the computer > > wich is running the software), but of the encryption algorithms used. > > > > So it can be compared to a package implementing md5: Yes, it's known > > that md5 is not secure any more, but that's not a reason to remove all > > packages implementing md5 from debian. > ... > > Therefore, I propose that encfs should be allowed into jessie. > > > > (What would be the right way to do that? Lower the severtiy of the bug? > > Add a jessie-ignore tag?) > > > > To notify users about the potential security issue, a NEWS file could > > be added, or one could add a warning to the output of the encfs command. > > In fact, that is what I considered as workaround, and even harder: add a > debconf message with priority critical telling exactly those details. > > Unless someone cries out loudly I will continue with this plan in a > couple of days. > > Regards, > Eduard. > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hi, Eduard Bloch: > So, I suggest this new version. Added below for review; I consider > uploading this to Experimental and submitting for l10n in a couple of > days. > Fair enough. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hallo, * Matthias Urlichs [Mon, Sep 29 2014, 07:29:44AM]: > > > According to a security audit by Taylor Hornby (Defuse Security), the > > > current > > > implementation of Encfs is vulnerable or potentially vulnerable to > > > multiple > > > attacks on the encrypted data. This especially affects use cases where > > > the > > > attacker has read/write access to the encrypted directory or has enough > > > knowledge of the unencrypted file system contents. > > > . > s/especially/only/, AFAIK. Maybe, but: "only" could sound like absolution to clueless users and I am not willing to make such suggestions. > > > In the current situation encfs should not be considered a safe home for > > > sensible data. This package should be only used to retrieve information > > > from > > s/sensible/sensitive/ Ouch, thank you. > > > previously encrypted sources, and even this action contains some risk of > > > receiving compromised data. > > > To recap the security analysis, as I understood it: There's a problem if > somebody has, or had, access to the encrypted files _and_ can store random > data of their choosing there (by manipulating either the encrypted or the > unencrypted files). The notice should unequivocally state exactly that, > instead of the current level of (IMHO) panic mongering. > > In most scenarios (encrypt some personal or corporate data stored on NFS, > use reverse mode to store an encrypted backup of sensitive stuff to the > cloud, whatever) this is a non-problem. I agree regarding most scenarios and I changed the text now. However, it's hard to keep the text understandable for average user and mention all relevant dangers without goind too much into details. So, I suggest this new version. Added below for review; I consider uploading this to Experimental and submitting for l10n in a couple of days. Regards, Eduard. Template: encfs/security-information Type: error _Description: Encfs security information According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example, an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without being noticed by the legimitate user, or may compute encryption information by timing analysis. . Until these issues are resolved, encfs should not be considered a safe home for sensitive data in certain scenarios. signature.asc Description: Digital signature
Bug#736066: Allow encfs into jessie?
Hi, Christian PERRIER: > > According to a security audit by Taylor Hornby (Defuse Security), the > > current > > implementation of Encfs is vulnerable or potentially vulnerable to multiple > > attacks on the encrypted data. This especially affects use cases where the > > attacker has read/write access to the encrypted directory or has enough > > knowledge of the unencrypted file system contents. > > . s/especially/only/, AFAIK. > > In the current situation encfs should not be considered a safe home for > > sensible data. This package should be only used to retrieve information > > from s/sensible/sensitive/ > > previously encrypted sources, and even this action contains some risk of > > receiving compromised data. > To recap the security analysis, as I understood it: There's a problem if somebody has, or had, access to the encrypted files _and_ can store random data of their choosing there (by manipulating either the encrypted or the unencrypted files). The notice should unequivocally state exactly that, instead of the current level of (IMHO) panic mongering. In most scenarios (encrypt some personal or corporate data stored on NFS, use reverse mode to store an encrypted backup of sensitive stuff to the cloud, whatever) this is a non-problem. -- -- Matthias Urlichs signature.asc Description: Digital signature
Bug#736066: Allow encfs into jessie?
Quoting Eduard Bloch (e...@gmx.de): > Template: encfs/security-information > Type: note > _Description: Encfs Security Information Besides using an Evil Debconf Note (;-) ), is there a reason for capitalizing every noun in the note title ? BTW, that might be a use case for the debconf "error" datatype which will emphasize the note even more on some frontends. > According to a security audit by Taylor Hornby (Defuse Security), the current > implementation of Encfs is vulnerable or potentially vulnerable to multiple > attacks on the encrypted data. This especially affects use cases where the > attacker has read/write access to the encrypted directory or has enough > knowledge of the unencrypted file system contents. > . > In the current situation encfs should not be considered a safe home for > sensible data. This package should be only used to retrieve information from > previously encrypted sources, and even this action contains some risk of > receiving compromised data. A call for translation would be appreciated too, of course. signature.asc Description: Digital signature
Bug#736066: Allow encfs into jessie?
Eduard Bloch writes:
> Hallo,
> * Eduard Bloch [Thu, Sep 11 2014, 04:55:14PM]:
>> > (What would be the right way to do that? Lower the severtiy of the bug?
>> > Add a jessie-ignore tag?)
>> >
>> > To notify users about the potential security issue, a NEWS file could
>> > be added, or one could add a warning to the output of the encfs command.
>>
>> In fact, that is what I considered as workaround, and even harder: add a
>> debconf message with priority critical telling exactly those details.
>>
>> Unless someone cries out loudly I will continue with this plan in a
>> couple of days.
>
> So, here is what I came up with. Does it sound scarry enough, does it
> sound generally acceptable?
>
> Template: encfs/security-information
> Type: note
> _Description: Encfs Security Information
> According to a security audit by Taylor Hornby (Defuse Security), the current
> implementation of Encfs is vulnerable or potentially vulnerable to multiple
> attacks on the encrypted data. This especially affects use cases where the
> attacker has read/write access to the encrypted directory or has enough
> knowledge of the unencrypted file system contents.
> .
> In the current situation encfs should not be considered a safe home for
> sensible data. This package should be only used to retrieve information from
| |
That should be "sensitive"|
|
+
and that should be "only be used", or perhaps "be used only for the retrieval
of..."
> previously encrypted sources, and even this action contains some risk of
> receiving compromised data.
This last sentence seems unclear to me. Are you saying that the act of
reading the data increases the chance of it being compromised? If so,
perhaps it should read:
... previously encrypted sources, and even performing this action carries
with it an increased risk of compromise.
Cheers, Phil.
--
|)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd.
|-| http://www.hands.com/http://ftp.uk.debian.org/
|(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY
pgpvNkuAjcyNt.pgp
Description: PGP signature
Bug#736066: Allow encfs into jessie?
Hallo, * Eduard Bloch [Thu, Sep 11 2014, 04:55:14PM]: > > (What would be the right way to do that? Lower the severtiy of the bug? > > Add a jessie-ignore tag?) > > > > To notify users about the potential security issue, a NEWS file could > > be added, or one could add a warning to the output of the encfs command. > > In fact, that is what I considered as workaround, and even harder: add a > debconf message with priority critical telling exactly those details. > > Unless someone cries out loudly I will continue with this plan in a > couple of days. So, here is what I came up with. Does it sound scarry enough, does it sound generally acceptable? Template: encfs/security-information Type: note _Description: Encfs Security Information According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple attacks on the encrypted data. This especially affects use cases where the attacker has read/write access to the encrypted directory or has enough knowledge of the unencrypted file system contents. . In the current situation encfs should not be considered a safe home for sensible data. This package should be only used to retrieve information from previously encrypted sources, and even this action contains some risk of receiving compromised data. Regards, Eduard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hi, Michael Halcrow: > > Finally, encfs has an interesting reverse crypto mode where it > > presents an encrypted FUSE view over a plaintext mountpoint. > > With eCryptfs, you would accomplish this by unmounting and then > reading the encrypted files directly from the lower file system. > This is not a replacement for encfs' Reverse Mode. Rev mode means that there _is_ no encrypted "lower file system". Reverse Mode means that you translate an unencrypted directory tree to an encrypted one, instead of vice versa. This is very useful for creating backups of critical data (which I cannot store on an encrypted FS, as that would be much too slow) to 'unsafe' remote media. > The incidentally lost or misplaced laptop is just about the only > adversarial model that the currently available data-at-rest encryption > options available for Linux can effectively address. > … or USB stick. > Do not expect any currently available encryption solutions to help you > much if you are individually targeted. > You need non-encrypted data to actually work with them. Thus an encrypted file system cannot and will not help make anything more secure if the FS in question is mounted anyway. That's pretty much a truism. In any case, yes encfs is not 100% safe, but frankly it's still much better than not encrypting data at all (esp. if the data to be stored is not controlled by an adversary) – and there currently is no better solution for a couple of important use cases. Thus, please bring it back. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
On 09/12/2014 06:46 AM, Jan Niehusmann wrote: > A common use case for disk encryption is to protect a lost or stolen > laptop. And the adversary is not some powerful agency, but a curious > person browsing through the hard disk before formatting it. > > I see no reason to assume that encfs is not good enough for that use > case, at the moment. There is, of course, also the problem of: what will people replace it with? I would suggest that some level of protection is better than none, and that the most likely outcome of removing encfs is no protection at all for a majority of users. Probably the most common suggestion, and only real option I am aware of, is ecryptfs. (LUKS and dm_crypt solve different problems.) Compared to encfs, ecryptfs is extremely difficult to use. For instance, by default, unlike encfs, you cannot change the password of ecryptfs data because the passphrase is directly transformed into the encryption key. After poring over poorly-documented things, I found a suggestion of how to work around this: 1) Generate an encryption key with od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | \ sed "s/^000//" | sed "s/\s*//g" 2) Pipe (I think!) the output from the above into ecryptfs-wrap-passphrase to encrypt it 3) Before mounting, run ecryptfs-insert-wrapped-passphrase-into-keyring pointing to the file saved in step 2 4) Save your precise mount options; in my case, ecryptfs_unlink_sigs,ecryptfs_fnek_sig=longstringhere,ecryptfs_key_bytes=32,ecryptfs_cipher=aes,ecryptfs_sig=anotherlongstring 5) Use those precise mount options later (These steps are rough; they may need a little tweaking but are close to the mark.) This is not friendly. At all. Additionally, although the ecryptfs audit at https://defuse.ca/audits/ecryptfs.htm produces fewer red flags than the encfs audit did, still its conclusion says "there are some red flags indicating it was not designed by a cryptographer." I also found mysterious bugs attempting to share the decrypted view of an ecryptfs volume using NFS. Finally, encfs has an interesting reverse crypto mode where it presents an encrypted FUSE view over a plaintext mountpoint. I can't find anything in the ecryptfs manpages about whether they're using SHA or MD5, but this RedHat bug from 2009 suggests it's using MD5. https://bugzilla.redhat.com/show_bug.cgi?id=490918 I do not know immediately why this was a red flag in encfs but not ecryptfs. I should also note that even if the authenticity features of encfs are less than perfect, it doesn't mean the package is useless. A person may, for instance, care more about the encryption than MAC features. >From what I can see, ecryptfs doesn't even have MAC at all. Let's warn people about things, of course, but drop something that's useful if not perfect? I don't think so. Encryption, for a lot of people, is making onesself a harder target. Let's face it, encfs, ecryptfs, dm_crypt, anything like that is probably not going to completely protect a running Internet-connected machine from every possible well-funded adversary, since once the encrypted data is mounted, it is accessible until the machine is turned off. Physical keyloggers, social engineering, etc. can also be a threat. None of these tools is perfect, but they are all an *improvement*. If a laptop is stolen from a coffee table by an opportunistic thief, and I know its screen was locked and the data on it was encrypted by one of the above tools, I can pretty much rest easy that at least my data is safe. Transparent encryption can be an important layer of data security, but it must not start or stop there for those truly concerned about it. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hi Holger, On Thu, Sep 11, 2014 at 06:42:32PM +0200, Holger Levsen wrote: > I (probably too briefly) skimmed though the bug report, but couldn't find a > usecase where an encrypted filestem container with broken crypto could be > useful. Could you elaborate, please? As far as I understand the EncFS Security Audit, encfs is not using 'broken crypto'. The conclusion of the audit states it quite clearly: "EncFS is probably safe as long as the adversary only gets one copy of the ciphertext and nothing more. EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times. EncFS attempts to protect files from malicious modification, but there are serious problems with this feature." (from https://defuse.ca/audits/encfs.htm) A common use case for disk encryption is to protect a lost or stolen laptop. And the adversary is not some powerful agency, but a curious person browsing through the hard disk before formatting it. I see no reason to assume that encfs is not good enough for that use case, at the moment. Of course, the crypto should be improved ASAP, as attacks to crypto only get better. Regards, Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
On Thu, Sep 11, 2014 at 04:06:06PM -0400, Harlan Lieberman-Berg wrote: > On Thu, 2014-09-11 at 19:33 +0200, Eduard Bloch wrote: > > I though Jan has just described one. For example, taking a 10 year old > > CD with backups from your safe and trying to get the data back. > > Another option would be to take the same approach that TrueCrypt did > under (potentially) the same circumstances, and allow encfs into jessie > - but only for read-only containers. That way, people can recover their > data easily, but there's no risk of perpetuating a completely broken > encryption layer. > > That'd be the best of both worlds, in my opinion. Note that some people have encfs encrypted HOME dirs by means of things like libpam-encfs. I do not think they will enjoy having their HOME partition suddenly become RO, even if can be recovered with the new package. They should of course be warned loudly that an old encryption layer is in use, with some potential risks. Another option would be a jessie encfs-ro package conflicting with encfs, but neither providing nor replacing it, so no new volumes are created. encfs would be kept out of jessie and once fixed it would manage to replace encfs-ro. However, the drawback is that the old encryption layer would still be present in upgraded systems until fix happens and reaches a stable release. I do not have a clear opinion about what is better. Regards, -- Agustin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
On Thu, 2014-09-11 at 19:33 +0200, Eduard Bloch wrote: > I though Jan has just described one. For example, taking a 10 year old > CD with backups from your safe and trying to get the data back. Another option would be to take the same approach that TrueCrypt did under (potentially) the same circumstances, and allow encfs into jessie - but only for read-only containers. That way, people can recover their data easily, but there's no risk of perpetuating a completely broken encryption layer. That'd be the best of both worlds, in my opinion. -- Harlan Lieberman-Berg ~hlieberman -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hi, On Donnerstag, 11. September 2014, Eduard Bloch wrote: > I though Jan has just described one. For example, taking a 10 year old > CD with backups from your safe and trying to get the data back. seems useful indeed, thanks. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#736066: Allow encfs into jessie?
On 11/09/2014 18:33, Eduard Bloch wrote: Otherwise we should disable support for 1024b GPG keys ASAP so nobody could use them anymore. Please also note, that the primary author (after a period of dormancy) is back and seems to be actively working on remediating the issues (cf. https://github.com/vgough/encfs). Best regards – Miroslaw Baran -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hallo, * Holger Levsen [Thu, Sep 11 2014, 06:42:32PM]: > Hi Eduard, > > On Donnerstag, 11. September 2014, Eduard Bloch wrote: > > In fact, that is what I considered as workaround, and even harder: add a > > debconf message with priority critical telling exactly those details. > > I (probably too briefly) skimmed though the bug report, but couldn't find a > usecase where an encrypted filestem container with broken crypto could be > useful. Could you elaborate, please? I though Jan has just described one. For example, taking a 10 year old CD with backups from your safe and trying to get the data back. Otherwise we should disable support for 1024b GPG keys ASAP so nobody could use them anymore. Regards, Eduard. signature.asc Description: Digital signature
Bug#736066: Allow encfs into jessie?
Hi Eduard, On Donnerstag, 11. September 2014, Eduard Bloch wrote: > In fact, that is what I considered as workaround, and even harder: add a > debconf message with priority critical telling exactly those details. I (probably too briefly) skimmed though the bug report, but couldn't find a usecase where an encrypted filestem container with broken crypto could be useful. Could you elaborate, please? cheers, Holger, curious signature.asc Description: This is a digitally signed message part.
Bug#736066: Allow encfs into jessie?
Hallo, * Jan Niehusmann [Thu, Sep 11 2014, 12:12:08PM]: > The bug report is about security issues, but these are not security > issues of the software (as in: you can somehow hack into the computer > wich is running the software), but of the encryption algorithms used. > > So it can be compared to a package implementing md5: Yes, it's known > that md5 is not secure any more, but that's not a reason to remove all > packages implementing md5 from debian. ... > Therefore, I propose that encfs should be allowed into jessie. > > (What would be the right way to do that? Lower the severtiy of the bug? > Add a jessie-ignore tag?) > > To notify users about the potential security issue, a NEWS file could > be added, or one could add a warning to the output of the encfs command. In fact, that is what I considered as workaround, and even harder: add a debconf message with priority critical telling exactly those details. Unless someone cries out loudly I will continue with this plan in a couple of days. Regards, Eduard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736066: Allow encfs into jessie?
Hi, due to bug #736066, encfs was removed from jessie. I'd think it would be better to allow encfs into jessie for the following reasons: The bug report is about security issues, but these are not security issues of the software (as in: you can somehow hack into the computer wich is running the software), but of the encryption algorithms used. So it can be compared to a package implementing md5: Yes, it's known that md5 is not secure any more, but that's not a reason to remove all packages implementing md5 from debian. One could argue that encfs shouldn't be used any longer to encrypt files, and therefore encfs is just not useful and can be removed. But many users will have legacy installations using encfs encrypted file systems, and will be surprised that they can't access them any more from jessie. So removing encfs will cause major inconveniences to some of our users. Therefore, I propose that encfs should be allowed into jessie. (What would be the right way to do that? Lower the severtiy of the bug? Add a jessie-ignore tag?) To notify users about the potential security issue, a NEWS file could be added, or one could add a warning to the output of the encfs command. Regards, Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
