[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150531133236.6ADCE6C003C@smtpvmsrv1.mitre.org>
Date: Sun, 31 May 2015 09:32:36 -0400 (EDT)
From: cve-assign@...re.org
To: ml-oss@...call.eu
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request for attic : encrypted backups attack
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> attic is a deduplicating backup program written in Python.
> It features encrypted remote backups.
>
> Unfortunately :
> https://github.com/jborg/attic/issues/271
> 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 :
> https://github.com/jborg/attic/commit/78f9ad1faba7193ca7f0acccbc13b1ff6ebf9072
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:
> https://github.com/jborg/attic/blob/master/docs/faq.rst
>
> 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
or
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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVaw0GAAoJEKllVAevmvmsKtEH/31saU48vhkXpcmwXa7ogWNs
VU8yKdnLV018/66+/A4rGOLxm/5Pe9uY3kVmULiHqffeL54d0mCUeyH60LG64key
StyLBAv4b36Zvt8kD367H8THp53abYXQlfIk4N769y2i3DUtMfEkL2GRLPW4U5eF
FUxerVWqhBNUWIYk8haGsLbqgTvPzaj46incW6/ls0P4f102yzMjDE6gWdVJBraq
iBauI23JJiPC8ZzVVyY+z/xJ6sV6E5zZav8YjbN52yw+5lstGPgjUcJ7Vlcq4o/7
VTwpYzsxEkDPHeDsFpbq+xsRapZA/eRqddIKbpxfP+DkIltaXhV95QtMKcbWbpg=
=Eu6l
-----END PGP SIGNATURE-----
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.
