A possible MD5 collision issue was found in the way Subversion handled cached credentials. If an attacker could trick a victim into connecting to their Subversion server, they could send a specially-crafted realm string to the victim that could trigger an MD5 collision. This could lead to the Subversion client sending another realm's credentials to the attacker's server. Upstream patches: http://svn.apache.org/r1550691 http://svn.apache.org/r1550772 References: http://mail-archives.apache.org/mod_mbox/subversion-dev/201406.mbox/%3C53915FD8.7050600@reser.org%3E
Created subversion tracking bugs for this issue: Affects: fedora-all [bug 1125800]
A CVE was requested here: http://mail-archives.apache.org/mod_mbox/subversion-dev/201407.mbox/%3C53DAB4A7.8030004@reser.org%3E
This was assigned CVE-2014-3528: http://seclists.org/oss-sec/2014/q3/275
When connecting to a subversion repository that requires password authentication, subversion client can save provided authentication credentials in a local file after prompting user. Passwords are saved in a file as: ~/.subversion/auth/svn.simple/<md5 hash> The md5 hash is MD5 checksum of a realm string that consists of remote server's scheme, hostname, and port, and an HTTP base authentication realm. For example, realm string for the upstream Subversion repository is "<https://svn.apache.org:443> ASF Committers" with an MD5 checksum of d3c8a345b14f6a1b42251aef8027ab57. For an attack, a developer known to have authentication credentials cached for a specific repository must be convinced to use svn to access different repository, which uses URL and realm that hash to the same string as the URL and realm of the trusted repository. That would cause svn to send saved credentials for the different repository to the attacker server, as svn only picked credentials based on MD5 checksum and did not check full URL and realm. As attacker does not control URL and realm of the trusted repository, they can not use known efficient ways to construct collisions. This rather requires a preimage attack. As there is currently no known efficient preimage attack against MD5, impact of this flaw is very limited. There are authentication provider in svn that call the affected svn_config_read_auth_data() function. MD5 collision seems to have no or very limited security impact for those, as they are used to store server's SSL certificate, store client's SSL certificate, store pass phrase for client certificate, or provide repository user name.
This issue affects subversion versions shipped with Red Hat Enterprise Linux 5, 6, and 7. Given the limited impact, and the life cycle phase Red Hat Enterprise Linux 5 is in at the moment, this issue is not currently planned to be fixed there. Future updates may correct this issue in newer Red Hat Enterprise Linux versions.
External References: http://subversion.apache.org/security/CVE-2014-3528-advisory.txt
subversion-1.7.18-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:0165 https://rhn.redhat.com/errata/RHSA-2015-0165.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:0166 https://rhn.redhat.com/errata/RHSA-2015-0166.html
Statement: Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates. For additional information, refer to the Red Hat Enterprise Linux Life Cycle: https://access.redhat.com/support/policy/updates/errata/.