oss-sec mailing list archives
Re: rsync vulnerable to collisions
From: Loganaden Velvindron <loganaden () gmail com>
Date: Mon, 28 Jul 2014 11:06:11 +0400
On Mon, Jul 28, 2014 at 5:18 AM, Michael Samuel <mik () miknet net> wrote:
Hi, After some semi-public discussion on Twitter I have come up with a method of creating blocks that collide under the rsync algorithm. The rsync algorithm consists of two checksums - a rolling sum based off Addler32 (notable difference - it doesn't use a prime modulus in rsync), and MD5. MD4 was used before rsync 3 (protocol version < 30), so presumably the change was introduced do to security concerns about MD4. Fast MD5 collisions have existed for quote some time - the attack I used as a basis is from 2006, and the much more serious chosen-prefix collision is from 2009. Generating a collision on my desktop PC takes less than a minute. I have not yet created a chosen-prefix collision, but I believe a similar technique is possible. Note that rsyncing a file over itself with two colliding blocks will not break rsync as it prefers copying data from it's original location. The minimum requirement is that an attacker can write to synced file twice - the process would need to be: - introduce collision 1 - rsync - introduce collision 2 - rsync Also note that a full file md5sum is calculated, so introducing these collisions would cause rsync to fail for that file (DoS attack)... unless it's the first block you're switching. If you use --inplace, the change is introduced despite the error message - this may be common when moving around virtual machine images or databases. Note that changing the block size is not a very effective mitigation (the collision can be aligned to both block sizes), and the checksum seed doesn't help - it should've been fed into md5 before the data, not after. I provided colliding blocks to both Wayne Davison and the Internet Bug Bounty a week ago. The IBB ticket is still sitting in New, and my last response from Wayne was effectively denying that this is a vulnerability. Since this information is known to the few that follow me on Twitter, I have decided it best to inform oss-security. I provided Wayne with some rather awful patches that bring in libdetectcoll and blake2b. He has not provided feedback, so I have not done further work on this. I won't provide full details yet, but if any distributions would like some collisions to perform specific tests (perhaps on Openstack Swift), please get in contact privately. For more information of MD5 colliisons and libdetectcoll, please see Marc Stevens' excellent work: https://marc-stevens.nl/research/
This will certainly cause issues with people running rsyncd for file synchronisation. I think that it might be a good idea to switch to another hashing algorithm, or at least offer an alternative to MD5.
Regards, Michael
-- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
Current thread:
- rsync vulnerable to collisions Michael Samuel (Jul 27)
- Re: rsync vulnerable to collisions Loganaden Velvindron (Jul 28)