Copying rsync information form bug 1126712: Michael Samuel discovered that rsync was vulnerable to checksum collisions. This could prevent rsync from running and syncing files successfully, which could break various applications that use and rely on rsync. Details are available in the original report: http://www.openwall.com/lists/oss-security/2014/07/28/1 This will require work with upstream to bring in Michael's proposed libdetectcoll and blake2b changes/get rsync to use something other than MD5.
The related collision issues for rsync and librsync (which are, despite the similar names, different implementations of the rsync algorithms) were originally both tracked under bug 1126712. However, they should be tracked independently as different implementations will need different CVEs assigned. CVE-2014-8242 assigned so far is applicable to librsync only - see bug 1126712 comment 14. Existing rsync Fedora tracker is bug 1126713.
Public test case / reproducer: https://github.com/therealmik/rsync-collision
The rsync git source now has a new commit with a simple fix to avoid this issue: it adds a negotiated-compatibility flag that indicates that it can process the checksum seed in the proper order (prior to the data instead of after), which avoids these calculated collisions. The fix is simple enough that it could be applied to any 3.x version of rsync, allowing it to interact with any other patched (or unpatched) 3.x version, no matter the protocol version used (if both are patched, the new seed order is used). Also note that older rsyncs used md4 checksums that had the seed value in the right order, so interacting with a pre-3.x rsync isn't affected by this issue either (and indeed, someone could use the --protocol=29 option in an unpatched rsync to avoid the issue as well). https://git.samba.org/?p=rsync.git;a=commit;h=eac858085e3ac94ec0ab5061d11f52652c90a869