Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 31 May 2015 09:32:36 -0400 (EDT)
Subject: Re: CVE request for attic : encrypted backups attack

Hash: SHA1

> attic is a deduplicating backup program written in Python.
> It features encrypted remote backups.
> Unfortunately :
> allow an attacker able to modify a remote encrypted directory to cause the
> client to send unencrypted data on the next backup run.
> It was fixed in this commit :

As far as we can tell, this means that the client determines whether
to send encrypted or unencrypted data by asking the server about the
value of the "manifest type byte" stored on the server.

The reported security problem is that the client user is not asked to
confirm that unencrypted data is acceptable. There are two cases
(either the repository has never been used, or the repository has
previously been used for encrypted data), but these are conceptually
the same. Use CVE-2015-4082.

A separate question is whether there is any remaining vulnerability.
The documentation says:

> When backing up to remote servers, is data encrypted before leaving
> the local machine, or do I have to trust that the remote server isn't
> malicious?
> Yes, everything is encrypted before leaving the local machine.

We also know that use of remote servers for unencrypted data is
intentional functionality, as long as the client user has previously
agreed to send unencrypted data to that server.

It seems that for this advertised functionality, normally, a client's
decision on whether to encrypt would be specified in the client's
configuration, on the client's command line, or in a client-side user
interface. Asking the server seems to be an unusual design decision.
(Conceivably, it is unusual enough to have its own CVE, but we are
not sure about that.) A potentially problematic case would be a user
who uses attic from many client machines, communicating with many
servers, and intentionally chooses to encrypt in some cases but not
all. The user goes to one client machine and types:

  ATTIC_PASSPHRASE="My secret passphrase" attic create storage::second my\ data

but has forgotten that the applicable server has always been set up
for unencrypted use. Maybe a safer alternative would be for a client
to always send encrypted data unless:

  A. an option such as --cleartext is on the command line


  B. the client configuration specifies cleartext and the attic
     process does not have access to a passphrase

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


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.