Marlinspike points out that the X.509 standard is really a collection of inconsistent hackery based upon an obscure protocol (ASN.1) with shaky construction and parsing between vendors.
The crux of the first attack: leverage one of the ASN.1 strings inside the certificate (ASN.1 uses a prefixed length value followed by the characters) by first prefixing an ASCIIZ (null-terminated) string. In this case, a PayPal ASCIIZ string is slapped in front of Moxie's domain. Amazingly enough, most SSL packages would treat this string as the real PayPal domain!
Every mainstream browser was susceptible to the attack and Marlinspike went on to demonstrate additional variations that suppressed certificate revocation (OCSP); hijacked Firefox's automatic software update feature; and provided a vector for remote code execution using the browser's flawed cert handling.
Marlinspike's vulnerabilities were revealed in July of 2009. How long did it take the two major browsers to remediate the findings?
• It took The Mozilla Project roughly three days to issue a new version of Firefox that addressed the bugs.
• It took Microsoft about ten weeks to issue a version of Internet Explorer that addressed the vulnerabilities ("Microsoft's Patch Tuesday fixes record number of flaws... The flaw in Microsoft's CryptoAPI, was disclosed 10 weeks ago, but took on more urgency after a hacker published a counterfeit certificate for PayPal that made it trivial for someone mounting a man-in-the-middle attack to impersonate the online payment processor...").
So if you're looking for some benchmarking to compare the relative security of open source and proprietary software products, Marlinspike's clever SSL hackery is as good a case study as any.
ASN.1 is not an "obscure protocol" at all. It's a well-established data specification and encoding standard that has been around for about 25 years. It is still alive and well, and today it is being used in many critical applications, such as, for example, the latest generations of cellular networks (e.g., HSPA and LTE). It doesn't make any sense to blame ASN.1 for the mistakes made by some developers when dealing with ASN.1 specifications. More information about ASN.1 can be found on http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
Unfortunately, it would not be so much fun to write a blog entry blaming it all (correctly!) to the C language and PDP hardware, where ASCIIZ strings were born. We still can't forget about this legacy when writing new software, even when the reasonable standard says UTF-8 or IA5 (ASCII) with no embedded '\0' permitted.
Almost nothing to do with ASN.1.
This kind of information is very limited on internet. Nice to find the post related to my searching criteria. Your updated and informative post will be appreciated by blog loving people.
Post a Comment