[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <FC72FC641B949240B947AC6F1F83FBAF09033BB9@IMCMBX01.MITRE.ORG>
Date: Tue, 12 Mar 2013 15:36:24 +0000
From: "Christey, Steven M." <coley@...re.org>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: CVE assignments for "weak" crypto (was CVE Request: MD5 used for
Download verification)
All,
This is an informal response, but I wanted to get something out pretty quickly.
For CVE, our default position is that "using MD5 for integrity checking of downloads" is a security-hardening issue, and thus should NOT receive a CVE ID. While MD5 may be "broken" from a theoretical standpoint, and there have been some demonstrations of collisions, and stronger options exist - I do not know of any reliable means of efficiently generating a collision that would also remain a functioning executable. There is also a strong likelihood of debate as to which method is currently "strongest."
The fundamental problem is in the MD5 algorithm itself; any implementation of MD5 will suffer from the same problems. We have multiple CVE identifiers for the various weaknesses of MD5. Any product that uses MD5 is therefore subject to these weaknesses.
By a long-running CVE practice, implementations should not receive their own CVEs for a fundamental flaw in a design that they implement. (Admittedly, CVEs are sometimes assigned accidentally, but this is actively discouraged.)
Admittedly, there can be a fuzzy line between "hardening" and a "vulnerability." And, as CVE and various security practices get "older," what was once strong at one time may be regarded as weak at a later time. Further complicating "strong" vs. "weak" is the development of massively-parallel attacks for some algorithms, e.g. password cracking against various hash algorithms that are still very strong, even by today's standards. I am aware of some efforts in quantifying security of cryptographic algorithms (e.g. by DJ Bernstein), but such work has not reached widespread adoption.
Informally, CVE guidance is as follows.
If a product uses a widely-known, common security algorithm (such as "hashing" or "encryption") that is regarded as "weak" (but not "completely broken"), the product may receive a CVE ID if either:
- the product uses "weak" encryption/hashing when a stronger option is available and implemented [which CVE regards as an issue in the implementation, which should choose the strongest option available unless otherwise directed by the product admin]; OR
- the product maintainer agrees that use of "weak" encryption/hashing poses a vulnerability; modifies the product to use a stronger option; and wishes to use a CVE ID to communicate to the product consumers that a fix really should be applied.
In the original request for Python setuptools/distribute, it appears that the issue is the use of MD5 for integrity checking, but we are not told whether the product implements stronger algorithms, or if the vendor has agreed that these pose a vulnerability for the product. So, at this point in time, there is not enough evidence to assign a CVE.
- Steve
>-----Original Message-----
>From: Donald Stufft [mailto:donald@...fft.io]
>Sent: Monday, March 11, 2013 3:33 PM
>To: oss-security@...ts.openwall.com
>Subject: [oss-security] CVE Request: MD5 used for Download verification
>
>I'd like to request CVE(s?) for the Python software: setuptools[1] and
>distribute[2]
>
>Setuptools (and it's fork distribute) utilize MD5 in order to verify that a
>download has not been tampered with.
>
>As far as I know this affects all versions of both setuptools and distribute.
>
>It also affects zc.buildout[3] which utilizes the md5 checking from distribute. It
>does not affect pip[4] as pip has grown it's own handling code outside of
>setuptools/distribute to allow stronger hashes.
>
>[1] https://pypi.python.org/pypi/setuptools/0.6c11
>[2] https://pypi.python.org/pypi/distribute/0.6.35
>[3] https://pypi.python.org/pypi/zc.buildout/2.0.1
>[4] https://pypi.python.org/pypi/pip/1.3.1
>
>-----------------
>Donald Stufft
>PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>DCFA
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
