[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] rsync vulnerable to collisions
From:       Loganaden Velvindron <loganaden () gmail ! com>
Date:       2014-07-28 7:06:11
Message-ID: CAOp4FwT7-6=AaS+kyoyLreugeZLK5mdZ0=bDf8w7xm4joMtg2g () mail ! gmail ! com
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]