Date: Mon, 26 May 2008 19:22:02 +0300
From: Aviram Jenik <aviram@...ondsecurity.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Advisory - Rsyncrypto maybe affected from Debian
	OpenSSL reduced entropy problem

Subject: Advisory - Rsyncrypto maybe affected from Debian OpenSSL reduced 
entropy problem
Date: Friday 23 May 2008
From: Shachar Shemesh <shachar@...gnu.com>
To: L-rsyncrypto <rsyncrypto-devel@...ts.sourceforge.net>


Background

Rsyncrypto[1] is a file encryption tool. It has a single RSA key that 
encrypts symmetric AES keys per file. The files themselves are subject 
to an encryption method that is based on CBC, but does a 
security-performance trade off. In particular, the files are encrypted 
in such a way that re-encrypting, using the same key, a file that was 
slightly modified will result in slightly modified cypher text. This is 
needed so that the file will retain wire efficiency when transferred 
using rsync[2].

Rsyncrypto does not generate the RSA itself. Instead, the rsyncrypto 
manual instructs the user to use openssl in order to generate a private 
key and a X509 certificate, and rsyncrypto will use either one of those.

Vulnerability

Rsyncrypto itself is unaffected by the openssl vulnerability introduced 
into Debian[3][4]. The common use scenario, however, will lead users 
toward generating predictable keys. This advisory is in place to warn 
users about possible exposure.

As with the original advisory, this problem will affect you even if you 
are not currently running on a vulnerable machine, or even on a Debian 
or derivative OS. If your keys were generated on a vulnerable machine, 
then your data is at risk.

Solution

First of all, users should make sure that they are running a version of 
openssl that does not exhibit the problem. See the OpenSSL advisory for 
your platform for details.

Users should regenerate the RSA key and X509 certificate used, and 
re-encrypt all files using the new key. User should perform a clean 
re-encryption, disregarding all context files rsyncrytpo saves, 
including the file name mapping file and the symmetric key files. This 
will, unfortunately, result in an encryption set that will not be 
transferable in a rsync friendly way.

Less Secure Solution - Security Performance Trade Off

If the user is 100% sure that no attacker has had a chance to save an 
encrypted file for later attack, one can make do with regenerating a new 
RSA key and re-encrypting the files using the existing state files (file 
name mapping and symmetric key files). This will result in encrypted 
files that have only their header different, but otherwise have the same 
name and data pay load. This should result in an easy rsync transfer of 
the files to the remote location.

Be warned, however, that should the assumption of no malicious access 
prove wrong, the attacker could recover the symmetric key used for 
encrypting the specific file. This means that the attack could read the 
file before the key update (unavoidable), but also read ALL FUTURE 
ENCRYPTIONS DONE WITH THE SAME KEY. In other words, if the attacker had 
any access to the file in the past, they can read all future versions as 
well unless the symmetric key is also replaced.

Mitigating Factors

None that may be relied on.

Rsyncrypto does not broadcast the public key used to encrypt the file. 
This makes an attacker's life harder, as she has to guess the key length 
as well as the actual key. Be warned, however, that small files leak the 
length of the key by nature of their size. Encrypting an empty file, for 
example, will always result in a same size cypher text file. Also notice 
that key lengths are rarely an arbitrary number. They are usually either 
1024, 1536, 2048 or 4096 bits, which means that the attacker only has 
two more bits of entropy to go through.

In short, do not rely on any of the mitigating factors.

[1] - http://sourceforge.net/projects/rsyncrypto
[2] - http://samba.anu.edu.au/rsync/
[3] - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166
[4] - http://www.debian.org/security/2008/dsa-1571

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists