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.
Created rsync tracking bugs for this issue: Affects: fedora-all [bug 1126713]
CVE request, and also noting that librsync is vulnerable to collisions too: http://www.openwall.com/lists/oss-security/2014/08/05/5
Created librsync tracking bugs for this issue: Affects: fedora-all [bug 1126718] Affects: epel-all [bug 1126719]
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.
Are there any details that would suggest we're dealing with a security issue (denial of service *attack*)?
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.
Exploits are public now: https://github.com/therealmik/librsync-collision https://github.com/therealmik/rsync-collision
Is a fix for librsync meanwhile available? Did I overlook something?
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.
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).
CVE-2014-8242 was assigned for this vulnerability in librsync. This CVE ID does not apply to rsync.
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.
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.
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.
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.
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.
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.
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.
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.
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.