CVE assignments for "weak" crypto (was CVE Request: MD5 used for Download verification)

["Christey, Steven M." <coley () mitre org>]

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 () stufft io]
> Sent: Monday, March 11, 2013 3:33 PM
> To: oss-security () lists 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