multiple security issues discovered in encfs

Debian Bug report logs - #736066
multiple security issues discovered in encfs

Reply or subscribe to this bug.

Toggle useless messages

---

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

Package: encfs
Version: 1.7.4-2.4+b2

A recent report discusses some issues with encfs. I do not have the
competence to judge it, but it is a good idea it at lease comes to the
users and package maintainers knowledge.

See https://defuse.ca/audits/encfs.htm

Paul

---

Message #14 received at 736066@bugs.debian.org (full text, mbox, reply):

Hi,

https://defuse.ca/audits/encfs.htm discusses a number of issues in EncFS:

"Same Key Used for Encryption and Authentication"

"Stream Cipher Used to Encrypt Last File Block"

"Generating Block IV by XORing Block Number"

"File Holes are Not Authenticated"

"MACs Not Compared in Constant Time"

"64-bit MACs"

"Editing Configuration File Disables MACs"

There are currently no patches.

I am not familiar enough with cryptography to know if they need CVEs, or 
are considered hardening (the last one sounds CVE worthy though)

Cheers,

--
Murray McAllister / Red Hat Security Response Team

https://bugzilla.redhat.com/show_bug.cgi?id=1097537

---

Message #19 received at 736066@bugs.debian.org (full text, mbox, reply):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> https://defuse.ca/audits/encfs.htm
> the last one sounds CVE worthy

Use CVE-2014-3462 for that issue, i.e., 'The purpose of MAC headers is
to prevent an attacker with read/write access to the ciphertext from
being able to make changes without being detected. Unfortunately, this
feature provides little security, since it is controlled by an option
in the .encfs6.xml configuration file (part of the ciphertext), so the
attacker can just disable it by setting "blockMACBytes" to 0 and
adding 8 to "blockMACRandBytes" (so that the MAC is not interpreted as
data).'

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)

iQEcBAEBAgAGBQJTcwbzAAoJEKllVAevmvms59MIALliH0nQBEhTa971v2fghjQS
XW43V8j42cD4i2yR91GfhJMCilyrRlxY1IQS7isleOQNBufmUavOs4gZmq1A+EGv
YD7F7MrQjLOKGLyl1aGbr5YpNmbYJONgqDnnpDdramjKo1MZKr/qexOLn51lLJQJ
J1RUaZIm+tccToBmkyhHS6rmHF/kutlvXt1goHKPkWaBWIdCz8zkPZWASj1D4KYX
Ynxtc+ikC60AdhQp1ggTmWff0NDnfjI7DUDWM88DbfLfGJ48/uAatgcEhKns326l
Z4eomykAB4IA62fgm0XisPrXNpibQs2aEOfr3fDwyCRBi7IA5y7C2SCFZ9V37bM=
=Rfv2
-----END PGP SIGNATURE-----

---

Message #24 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Encfs still has its uses despite the security problems.
With this bug filed as serious it has now disappeared from jessie.

-- 
------------------------------------------------------------------------
Frank Kingswood                         frank@kingswood-consulting.co.uk
Cambridge, United Kingdom                               +44-7545-209 100

[Message part 2 (text/html, inline)]

---

Message #29 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #34 received at 736066@bugs.debian.org (full text, mbox, reply):

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.

---

Message #39 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

---

Message #44 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

---

Message #49 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #54 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

---

Message #59 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #64 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #69 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #74 received at 736066@bugs.debian.org (full text, mbox, reply):

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/^0000000//" | 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

---

Message #79 received at 736066@bugs.debian.org (full text, mbox, reply):

On Fri, Sep 12, 2014 at 11:58:04AM -0500, John Goerzen wrote:
> 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

I did most of the work in forking and rewriting Cryptfs as eCryptfs.
I designed its encryption and key management, and I also wrote most of
the initial release of the userspace toolchain.

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

Each file gets its own randomly generated data encryption key known as
a FEK.  This key is wrapped with the wrapping key (FEKEK) retrieved
from the user's session keyring.  The signature for the FEKEK to use
for newly created files is the ecryptfs_sig= mount option.  By having
the old FEKEK and the new FEKEK in the user session keyring and by
mounting with the new FEKEK as ecryptfs_sig=, you will role both the
FEK and FEKEK when you make a copy of any file.  This isn't documented
and there's no toolchain available to automate this at the moment.

>  After poring over poorly-documented things, I found a suggestion of how
> to work around this:

Agreed.  Much documentation is definitely lacking.

> 1) Generate an encryption key with
> 
>     od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | \
>     sed "s/^0000000//" | 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.

Agreed.  Ubuntu distilled the complexity into a single checkbox in the
installer, which gives a much more reasonable story for the typical
desktop user.  However there's still far too much technical detail
exposed to the user, which has resulted in many users shooting
themselves in the foot -- e.g., by naively deleting their ~/.ecryptfs
directories in a misguided attempt to free up disk space.

I'm taking the lessons learned from years of experience with eCryptfs
out in the wild and seeing if I can do a better job in a file system
native solution.

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

The design was reviewed by industry-recognized cryptographers at IBM
Research.

> I also found mysterious bugs attempting to share the decrypted view of
> an ecryptfs volume using NFS.

The ideal of stacking in Linux was a nice fantasy, but it hasn't been
realized in practice.  NFS is one of several examples where it just
hasn't worked out.  That's one of the reasons why I'm currently
working on a file system native solution.

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

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

MD5 has known weaknesses for specific applications.  Those weaknesses
have not been shown to apply to eCryptfs' use of MD5 in such a way so
as to substantially reduce its security.

That said, crypto attacks only get better, and so it's well advised to
use a hash that isn't known to have significant weaknesses.  I'm not
motivated to update eCryptfs since I honestly would like to see it
deprecated.

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

Correct.  This is one reason why I cannot currently recommend eCryptfs
given attacks against encryption that lacks integrity that have
surfaced in the past few years.  My work with native file system
encryption addresses this issue.

Aside from lack of integrity and some stacking incompatibilities,
there are a couple of correctness and performance issues with
eCryptfs:

 * Since the kernel doesn't support stacking semantics, there's no
   mechanism to propagate a page invalidation from a lower inode page
   cache to the eCryptfs inode page cache.  Unless you successfully
   hide all the dentry's for the lower inodes, eCryptfs can end up
   stomping over changes to the ciphertext -- i.e., by backup/restore
   utilities.

 * Actual file sizes are in the file contents.  Which makes directory
   enumeration result in an open and read of every lower file,
   impacting performance.

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

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.

Do not expect any currently available encryption solutions to help you
much if you are individually targeted.

> 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

If you're interested in my current work in ext4, here are my slides
from this year's Linux Security Summit:

http://kernsec.org/files/lss2014/Halcrow_EXT4_Encryption.pdf

My current patchset implementing phase 1 (w/out integrity) is in the
ext4 unstable branch:

http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/log/?h=unstable

If you have any suggestions from the distro integration side of
things, including how keys should be managed and passed to the kernel,
now would be a good time to let me know.

---

Message #84 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #89 received at 736066@bugs.debian.org (full text, mbox, reply):

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.

---

Message #94 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Eduard Bloch <edi@gmx.de> 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

[Message part 2 (application/pgp-signature, inline)]

---

Message #99 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Quoting Eduard Bloch (edi@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 (application/pgp-signature, inline)]

---

Message #104 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

---

Message #109 received at 736066@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

---

Message #114 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #119 received at 736066@bugs.debian.org (full text, mbox, reply):

Package: encfs
Version: 1.7.4-4.1
Followup-For: Bug #736066

While the security message itself is mostly-OK, could you please make sure
it's displayed _once_?

As it is, it's shown once before installing/updating the package, and
another time during the actual installation. That's annoying; besides,
I'd like to come back after triggering a dist-upgrade and _not_ see the
process stuck 10% through, waiting for an OK I already gave. :-/
-- 
-- Matthias Urlichs

---

Message #124 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Message #131 received at 736066@bugs.debian.org (full text, mbox, reply):

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

---

Send a report that this bug log contains spam.

---

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Jun 19 14:38:59 2019; Machine Name: beach

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.