Security

SSL certificates and MD5 collisions

There is a fair amount of confusion surrounding the recent research resulting in the ability to create bogus SSL certificates. The research combined a weakness in the certificate generation process with the ability to create MD5 hash collisions and generated a certificate that would be accepted by all browsers. That certificate could be used to sign other certificates, allowing the researchers to create a valid certificate purporting to be from any domain they chose.

Cryptographic hashes, like MD5, are used in digital signature algorithms; in effect it is the hash that is signed as a stand-in for the actual content. It has been known since 2004 that MD5 collisions—two different inputs generating the same hash value—could feasibly be found. So, a signature on data with a specific MD5 hash would be considered a valid signature on any other data that hashed to the same value. What the researchers did was to create a certificate that the certificate authority (CA), in this case RapidSSL, was willing to sign, then transferred that signature to a different certificate. That second certificate hashed to the same value, but had the ability to sign additional certificates.

This is a very significant attack on SSL that was addressed rather quickly. One wonders why these certificate authorities were still using MD5 long after it had been deprecated because of the collision vulnerability. Inertia is the likely culprit, but RapidSSL and other CAs using MD5 changed to SHA-1 within hours of the report in some cases. In addition, RapidSSL stopped using sequential serial numbers in certificates. That flaw helped the researchers immensely, so that they only needed four attempts (with a 200 node Playstation 3 cluster) to create their colliding certificate. A random serial number over a sizable range once again makes this attack infeasible—at least on today's hardware.

Eventually, MD5 will no longer be accepted as the hash used in the signatures on certificates—or anything else, probably—but as of now, SSL implementations will accept them. There are large numbers of such certificates in use today, so browsers cannot just stop accepting them. CAs are generally offering their customers free replacement certificates that use SHA-1. Because users rarely root through the certificates presented to their browser to determine what hash algorithm was used, there is a extension for Firefox called SSL Blacklist that detects these certificates and pops up a warning.

But, for those sites affected—LWN for example—it can be a bit worrying to hear from users that their certificate may be bad. The LWN certificate and countless others are really no more vulnerable to this attack than any other. A site that has an SHA-1 signature can be spoofed by this attack as easily as one with an MD5 signature. But a site that has an MD5 signed certificate does make it harder to switch away from MD5. That switch won't happen soon in any case, but it could be slowed down by sites that are slow to change.

If an attacker currently has a certificate of the type that the researchers created, they can use it to sign certificates for any domain they wish, and they can use SHA-1 in that signature. This particular vulnerability requires an MD5 signed certificate in the chain of certificates, but does not require that the final, domain-specific certificate be signed with MD5. It should also be noted that some of the root certificates distributed with browsers are MD5-signed. Those are not vulnerable because they are distributed with the browser—if an attacker can change one's root certificate stash, there are much easier attacks possible. For this reason, SSL Blacklist looks for MD5 signatures in the certificate chain anywhere after the root certificate.

This incident is a good illustration of how cryptographic research often proceeds. First, small cracks are found in an algorithm, causing some worry in cryptographic circles, then partial attacks are found, which generally starts to raise the alarm in the wider security community. But it usually takes a full-scale attack or proof-of-concept to really cause those who use the algorithms, knowingly or unknowingly, to take remedial action. That delay provides a nice window that attackers can and will exploit.

Comments (19 posted)

New vulnerabilities

bind: validation bypass

Comments (none posted)

cups: insecure tmp file usage

Comments (none posted)

gforge: insufficient input sanitizing

Comments (none posted)

git: arbitrary code execution

Comments (2 posted)

hplip: privilege escalation

Comments (1 posted)

imap: denial of service

Comments (none posted)

java: multiple vulnerabilities

Comments (none posted)

jhead: multiple vulnerabilities

Comments (none posted)

lasso: certificate verification bypass

Comments (none posted)

mplayer: arbitrary code execution

Comments (none posted)

ntp: signature verification vulnerability

Comments (none posted)

online-bookmarks: multiple vulnerabilities

Comments (none posted)

pam_mount: insecure tmp file usage

Comments (none posted)

pdnsb: denial of service

Comments (none posted)

python: multiple vulnerabilities

Comments (none posted)

qemu: password guessing

Comments (none posted)

Streamripper: multiple vulnerabilities

Comments (none posted)

vinagre: arbitrary code execution

Comments (none posted)

zaptel: arbitrary code execution

Comments (none posted)

Page editor: Jake Edge
Next page: Kernel development>>