Arch Linux Security Advisory ASA-201503-10
=========================================
Severity: Medium
Date    : 2015-03-16
CVE-ID  : CVE-2014-8242
Package : librsync
Type    : checksum collision
Remote  : Yes
Link    : https://wiki.archlinux.org/title/CVE

Summary
======
The package librsync before version 1.0.0-1 is vulnerable to checksum
collision leading to possible file modification or corruption via a
birthday attack.

Resolution
=========
Upgrade to 1.0.0-1.

# pacman -Syu "librsync>=1.0.0-1"

The problem has been fixed upstream in version 1.0.0.

Workaround
=========
None.

Description
==========
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.

Impact
=====
An attacker is able to take advantage of the weak checksum calculation
by using a birthday attack in order to corrupt or modify files that are
transfered.

References
=========
https://www.openwall.com/lists/oss-security/2014/07/28/1
https://access.redhat.com/security/cve/CVE-2014-8242
https://github.com/librsync/librsync/issues/5
https://bugs.archlinux.org/task/44175

ArchLinux: 201503-10: librsync: checksum collision

March 16, 2015

Summary

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.

Resolution

Upgrade to 1.0.0-1. # pacman -Syu "librsync>=1.0.0-1"
The problem has been fixed upstream in version 1.0.0.

References

https://www.openwall.com/lists/oss-security/2014/07/28/1 https://access.redhat.com/security/cve/CVE-2014-8242 https://github.com/librsync/librsync/issues/5 https://bugs.archlinux.org/task/44175

Severity
Package : librsync
Type : checksum collision
Remote : Yes
Link : https://wiki.archlinux.org/title/CVE

Workaround

None.

Related News