[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130312172453.GO4080@sentinelchicken.org>
Date: Tue, 12 Mar 2013 10:24:53 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: CVE assignments for "weak" crypto (was CVE
Request: MD5 used for Download verification)
Hi Steve,
I think maybe this position you outline doesn't go quite far enough to
distinguish between various attack scenarios. As Jeremy alluded to,
there are three primary attack scenarios against cryptographic hash
functions:
* Preimage
* Second preimage
* Collision
Each of these scenarios is VERY DIFFERENT in terms of complexity. In
addition, these attack scenarios generalize to all types of
cryptographic hashes. (This isn't some quirk of MD5 or Merkle-Damgard
based hashes or whatever.) Think of resistance to these attacks as
"features" offered by the hash algorithm. In this respect, the
difficulty of attacks isn't all that fuzzy; it is more cut and dried.
When people say "MD5 is broken", that isn't nearly descriptive enough
to help us understand in what scenarios it is broken. So people who
are concerned about security, but don't understand hashes, frequently
call out the use of MD5 for any reason as being bad. Most of the time
they are wrong about the risk, because the application isn't relying
on MD5's collision resistance. When an application uses a hash
function, it is relying on one or more of these properites to remain
secure, but rarely relies on all of them.
I think if an application relies on a cryptographic primitive for a
property that it does not provide, or that it is KNOWN to be broken
for (such as MD5 or SHA1 with collision resistance), then there should
be a CVE assigned. The cat's out of the bag on these things; there's
no excuse to use MD5 for this purpose. The world knows these hashes
are broken w.r.t collision resistance just as RC4 is broken in the
context of WEP (but not SSL/TLS) or that CBC mode is broken if you
don't wrap it in a MAC.
However, if someone uses a well salted MD5 for password hashing, then
no, there is no problem, therefore no CVE. I think it would help
security people (and eventually, developers) understand the difference
if the CVE took a more refined position on this.
tim
On Tue, Mar 12, 2013 at 03:36:24PM +0000, Christey, Steven M. wrote:
> 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.
