Bug 1197601

Summary:	rsync: MD5 collision DoS attack or limited file corruption
Product:	[Other] Security Response	Reporter:	Tomas Hoger <thoger>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	carnil, ssorce, vkrizan, wayned
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-20 10:50:27 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1124325

Description Tomas Hoger 2015-03-02 07:57:18 UTC

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.

Comment 1 Tomas Hoger 2015-03-02 08:03:33 UTC

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.

Comment 3 Tomas Hoger 2015-03-02 08:09:35 UTC

Public test case / reproducer:

https://github.com/therealmik/rsync-collision

Comment 4 Wayne Davison 2015-05-11 19:47:27 UTC

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