duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Stream Vulnerability


From: Nate Eldredge
Subject: Re: [Duplicity-talk] Stream Vulnerability
Date: Sun, 31 Aug 2014 09:53:36 -0600 (MDT)
User-agent: Alpine 2.10 (DEB 1266 2009-07-14)

On Fri, 29 Aug 2014, Jonathan Brown wrote:

Could anyone tell me if Duplicity is vulnerable to stream encryption
vulnerabilities utilizing GPG? This blog post talks about issues affecting
encryption that uses GPG and I would like to know if there is any reason to
be concerned. Thanks

https://www.imperialviolet.org/2014/06/27/streamingencryption.html

Summary of the article: GPG puts signatures, checksums, etc at the end of encrypted data. Therefore, when decrypting on the fly, the decrypted data is output before it can be checked for integrity. So a program might work on data that has been tampered with (e.g. if the data is a tar archive, unpacking it into the filesystem), and only find out after it is too late to reverse it (e.g. existing files are overwritten).

I looked into this, and to the best of my knowledge, duplicity is not vulnerable, for two reasons.

It looks like when restoring, duplicity does decrypt on-the-fly while processing difftar volumes from the temp directory. However, before decryption even begins, the volume's SHA1 hash is checked against the manifest, so a tampered volume would fail at this stage before being decrypted or unpacked. (If --sign-key is in use, which it should be if you have concerns that an attacker may be able to modify your backup data, the manifest will have already had its signature checked.) You would be left with an incompletely restored backup, possibly including a truncated file, but there would be no way for an attacker to use this to manipulate file contents.

Furthermore, even if such an attack could be carried out, it couldn't cause any damage. duplicity does not allow you to restore on top of existing data: if the target directory for the restore is not empty, it aborts. So even if altered data were written before being detected, it would have been written to a new directory. When the invalid hashes/signatures were detected and reported by duplicity, you could simply delete the restore directory, and your existing files would be intact.




--
Nate Eldredge
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]