Bug 1126712 (CVE-2014-8242) - CVE-2014-8242 librsync: MD4 collision file corruption
Summary: CVE-2014-8242 librsync: MD4 collision file corruption
Keywords:
Status: CLOSED UPSTREAM
Alias: CVE-2014-8242
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20140728,repor...
Depends On: 1126718 1126719
Blocks: 1124325
TreeView+ depends on / blocked
 
Reported: 2014-08-05 06:26 UTC by Murray McAllister
Modified: 2019-06-08 20:08 UTC (History)
6 users (show)

Fixed In Version: librsync 1.0.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-08 02:34:13 UTC


Attachments (Terms of Use)

Description Murray McAllister 2014-08-05 06:26:39 UTC
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 Murray McAllister 2014-08-05 06:28:31 UTC
Created rsync tracking bugs for this issue:

Affects: fedora-all [bug 1126713]

Comment 5 Murray McAllister 2014-08-05 06:53:49 UTC
CVE request, and also noting that librsync is vulnerable to collisions too:

http://www.openwall.com/lists/oss-security/2014/08/05/5

Comment 6 Murray McAllister 2014-08-05 06:54:36 UTC
Created librsync tracking bugs for this issue:

Affects: fedora-all [bug 1126718]
Affects: epel-all [bug 1126719]

Comment 7 Robert Scheck 2014-08-05 14:47:30 UTC
Murray, are you sure that librsync is affected? This library was previously
known as libhsync up to version 0.9.0. The current version of this package
does not implement the rsync network protocol and uses a delta format slightly 
more efficient than and incompatible with rsync 2.4.6.

Comment 8 Pavel Šimerda (pavlix) 2014-08-05 15:24:57 UTC
Are there any details that would suggest we're dealing with a security issue (denial of service *attack*)?

Comment 9 Michael Samuel 2014-08-05 23:32:11 UTC
Hi Robert,

I have tested and librsync is affected - although it isn't a DoS - it won't detect the change.

What it does is stamp a copy of the first instance of the collision over future instances.  A chosen-prefix attack is trivial due to the 64-bit hash (aka slightly more efficient), so for example you could make inode structures collide in a VM backup.

Also note that apps compiled against librsync will probably need recompiling after the patch ships, since RS_DEFAULT_STRONG_LEN will have to change.

(In reply to Robert Scheck from comment #7)
> Murray, are you sure that librsync is affected? This library was previously
> known as libhsync up to version 0.9.0. The current version of this package
> does not implement the rsync network protocol and uses a delta format
> slightly 
> more efficient than and incompatible with rsync 2.4.6.

Comment 11 Robert Scheck 2014-10-08 23:11:22 UTC
Is a fix for librsync meanwhile available? Did I overlook something?

Comment 12 Michael Samuel 2014-10-08 23:17:14 UTC
See upstream bug for history:
https://github.com/librsync/librsync/issues/5

Still almost no contact from rsync author at all.

I think 3 months is more than enough time for others to reproduce an exploit for a public vulnerability, so there was no point pretending that exploits don't exist/are hard.

Comment 13 Robert Scheck 2014-10-08 23:29:14 UTC
Thanks for the pointer. But given that I can't rate the patch suggestion at
all I would wait for an upstream patch/release of librsync - except somebody
else knowledged kicks in and makes a decision that is acceptable for Fedora
(preferably the Red Hat security team).

Comment 14 Vasyl Kaigorodov 2014-10-13 09:36:55 UTC
CVE-2014-8242 was assigned for this vulnerability in librsync.
This CVE ID does not apply to rsync.

Comment 16 Tomas Hoger 2015-03-02 08:11:43 UTC
Both rsync and librsync issues should not be tracked under this single bug.  As this bug is already referenced by a librsync Fedora update request, a separate bug 1197601 was created for the rsync issues.

Comment 17 Tomas Hoger 2015-03-02 08:21:56 UTC
A quick summary of links related to librsync.

Upstream bug:
https://github.com/librsync/librsync/issues/5

Reproducer:
https://github.com/therealmik/librsync-collision

CVE request:
http://www.openwall.com/lists/oss-security/2014/08/05/5
http://seclists.org/oss-sec/2014/q3/291

Fixed upstream in librsync 1.0.0 by introducing a backward-incompatible change that replaces MD4 hash with BLAKE2 by default.  It is still possible to enable use of MD4 for compatibility.

https://github.com/librsync/librsync/blob/e2d3bdf/NEWS

Quoting from the upstream NEWS file:

 * SECURITY: CVE-2014-8242: librsync previously used a truncated MD4
   "strong" check sum to match blocks. However, MD4 is not cryptographically
   strong. It's possible that an attacker who can control the contents of one
   part of a file could use it to control other regions of the file, if it's
   transferred using librsync/rdiff. For example this might occur in a
   database, mailbox, or VM image containing some attacker-controlled data.

   To mitigate this issue, signatures will by default be computed with a
   256-bit BLAKE2 hash. Old versions of librsync will complain about a
   bad magic number when given these signature files.

   Backward compatibility can be obtained using the new
   `rdiff sig --hash=md4`
   option or through specifying the "signature magic" in the API, but 
   this should not be used when either the old or new file contain 
   untrusted data.

   Deltas generated from those signatures will also use BLAKE2 during
   generation, but produce output that can be read by old versions.

   See https://github.com/librsync/librsync/issues/5

   Thanks to Michael Samuel <miknet.net> for reporting this and offering an
   initial patch.

Comment 18 Fedora Update System 2015-03-09 08:18:38 UTC
csync2-1.34-15.fc22, rdiff-backup-1.2.8-14.fc22, librsync-1.0.0-1.fc22, duplicity-0.6.25-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 19 Fedora Update System 2015-03-19 18:43:12 UTC
librsync-1.0.0-1.fc20, duplicity-0.6.25-3.fc20, csync2-1.34-15.fc20, rdiff-backup-1.2.8-14.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 20 Fedora Update System 2015-03-19 18:44:27 UTC
csync2-1.34-15.fc21, rdiff-backup-1.2.8-14.fc21, librsync-1.0.0-1.fc21, duplicity-0.6.25-3.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 21 Fedora Update System 2015-03-25 19:56:55 UTC
librsync-1.0.0-1.el5, rdiff-backup-1.0.5-3.el5, duplicity-0.6.21-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Fedora Update System 2015-03-25 19:57:43 UTC
librsync-1.0.0-1.el6, duplicity-0.6.22-4.el6, csync2-1.34-15.el6, rdiff-backup-1.2.8-6.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2015-03-25 20:00:52 UTC
duplicity-0.6.24-5.el7, librsync-1.0.0-1.el7, rdiff-backup-1.2.8-11.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 24 Product Security DevOps Team 2019-06-08 02:34:13 UTC
This CVE Bugzilla entry is for community support informational purposes only as it does not affect a package in a commercially supported Red Hat product. Refer to the dependent bugs for status of those individual community products.


Note You need to log in before you can comment on or make changes to this bug.