Hash-Kollision in csync2
ID: | FEDORA-2015-3366 |
Distribution: | Fedora |
Plattformen: | Fedora 20 |
Datum: | Fr, 20. März 2015, 00:02 |
Referenzen: | http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8242 |
Applikationen: | csync2 |
Originalnachricht |
|
Name : csync2 Product : Fedora 20 Version : 1.34 Release : 15.fc20 URL : http://oss.linbit.com/csync2/ Summary : Cluster synchronization tool Description : Csync2 is a cluster synchronization tool. It can be used to keep files on multiple hosts in a cluster in sync. Csync2 can handle complex setups with much more than just 2 hosts, handle file deletions and can detect conflicts. It is expedient for HA-clusters, HPC-clusters, COWs and server farms. -------------------------------------------------------------------------------- Update Information: Changes in librsync 1.0.0 (2015-01-23) ====================================== * 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 |