SSL flaws revealed at Black Hat

The annual Black Hat security conference in Las Vegas is probably the premier security event each year—at least for the disclosure of new vulnerabilities. The event usually has one or more high-profile disclosures that often lead to software vendors and projects scrambling to fix the vulnerable code. This year was no exception, with Secure Sockets Layer (SSL) taking center stage. Two of the vulnerabilities led to Mozilla security updates, while others showed flaws in the certificate authority (CA) infrastructure and browser handling of Extended Validation (EV) SSL certificates.

The most serious problem would seem to be a disconnect between CAs and browsers on how to handle certificates with NUL (i.e. '\0') bytes in the domain name. CAs have been willing to issue certificates for host/domain names containing NULs, but browsers were handling them in ways that made certificate spoofing much easier. Moxie Marlinspike and Dan Kaminsky independently discovered the problem and both presented about it at Black Hat. Marlinspike's example was a certificate issued for www.paypal.com\0.thoughtcrime.org, which would appear to be a legitimate PayPal certificate to the browser user.

It has been argued that the CAs should not be issuing certificates of that sort, especially given that C-based programs interpret NUL as the end of string, but the browsers have a certain amount of responsibility here as well. It's hard to see a legitimate use for a certificate with a NUL byte as part of the domain name, but browsers could and should have used the string length, which is specified in the certificate to determine how to display and handle the domain name. The CAs should also stop signing such certificates, and revoke those that they have already issued, but that, of course, doesn't stop anyone from self-signing a certificate with a NUL byte in the domain name.

The flaw could be exploited to do a man-in-the-middle attack against users. An attacker who could intercept network traffic—via a compromised, or just maliciously configured, wireless router for example—could present one of these certificates when a victim visited PayPal. Because the browser only looked at the host name information before the NUL, the user would believe they had a secure session with PayPal, when, in fact, they were talking to a host under the attacker's control.

Marlinspike found another problem, which only seems to have affected the Firefox 3.0 series, in how wildcards were handled in the host names presented in certificates. Wildcard certificates are meant to solve the problem of multiple hosts in a given domain that need to share certificates. So, a CA could sign a single certificate that would work for webhost00.example.com through webhost99.example.com. Firefox 3.0 and earlier supported a non-standard Netscape regular expression syntax which Marlinspike found a way to exploit.

That exploit would cause a heap overflow that could allow arbitrary code execution—another particularly nasty outcome. According to the Mozilla advisory: "With version 3.5 Firefox switched to the more limited industry-standard wildcard syntax instead and is not vulnerable to this flaw."

Kaminsky's talk also covered a number of other issues with SSL certificate handling. Red Hat's director of security response Mark Cox summarized those problems along with their impact on various free software packages. For the most part, they had much less impact than the NUL-byte spoofing attack, which Cox notes as having been fixed in April for Firefox 3.5 in RHEL.

Another presentation on SSL came from Alexander Sotirov and Mike Zusman. They showed that EV certificates can be replaced with valid, conventional (aka Domain Validated or DV) certificates without changing the browsers display to reflect the potentially reduced security. Browsers display sites using EV certificates in green in the address bar to denote the supposed higher security. By using a man-in-the-middle attack, and a valid DV certificate for the domain, they were able to send the second certificate, which caused the browser to switch encryption keys to that contained in the DV certificate. So the session was secured with the "lesser" DV certificate, which the attacker controlled, but still showed the green address bar.

Zusman also gave a presentation at DefCon (which follows Black Hat) on the reliability of the web applications that CAs use for handling certificate requests. As might be guessed, they turn out to be vulnerable to the usual web application suspects: cross-site scripting and SQL injection, but he found additional problems as well. He was able to circumvent the domain name validation used by some CAs so that he could get certificates for domains that he did not control.

It is rather worrisome that the CAs, who are supposedly guarding the safety of web traffic, are so lax about the security of their own applications. As Zusman noted in the article: "If you can game a CA's validation mechanism, they don't get hurt — they might even make some money. [Those] who suffer are those who use the Internet."

SSL is an important part of the web infrastructure that users must rely on daily to protect their communications with sensitive sites. It is not surprising that it would be targeted by security researchers, nor is it all that surprising that problems were found. While attacks against these specific problems may be difficult to pull off in practice, they represent holes that clearly need to be filled. If security researchers are finding these kinds of problems, it's pretty likely that attackers are finding them as well—but the attackers are much less likely to tell us about it at Black Hat.