Looking past the 23 Critical Internet Explorer remote code execution vulnerabilities being patched this month by MS14-037 that require immediate attention, most interesting is CVE-2014-2783, the Internet Explorer “Extended Validation (EV) Certificate Security Feature Bypass Vulnerability”. The vulnerability itself, reported by Eric Lawrence of “Fiddler” fame, is applicable in a “corner case” situation and can lead to man-in-the-middle (MiTM) attacks.
Let’s narrow down the complexity of the issue for everyone’s sake. What is an “EV” certificate? Well, it’s a special certificate that an organization or individual would pay extra money to a certificate authority like Verisign to create and then use to “secure” their communications. Sites using them are usually handled in a special manner by the major web browsers. The address bar turns green, a special rectangle is set around the address, or some other visual image assures the user that the connection is with the right web site and encrypted. Here is an example of a web browser presenting the green bar EV visualization, please click on the image for a closeup:
The related flaw being patched this month is a tricky one. Internet Explorer versions 7 through 11 all allow for wildcard subdomains with EV Certificates, which should never be allowed. Neither Certificate Authorities nor web browsers should allow for such a flaw, but their compliance is questionable. In the past, CAs like Diginotar, Comodo, Trustwave, TurkTrust, and currently the National Informatics Centre in India, all maintained incidents of major improprieties at the CA level.
So, coupled with this flaw in IE 7,8,9,10 and 11, attackers (whether or not they are state sponsored or more traditional cybercrime organizations) could set up sites with wildcard EV certs to spoof major web properties like at google, twitter, facebook and elsewhere, and steal data from sensitive communications there. The Certificate Authority infrastructure trust model continues to show major cracks as a flawed trust model, and this “corner case” simply enables more situations like it. Potential solutions like Convergence have not been seriously pushed. At the same time, cheers to Microsoft for patching and reporting on the two current issues.
Unfortunately, these sorts of issues find their way into software products all the time. Partly, they are very tricky to understand by QA teams and developers certainly need to narrow the scope of their projects. You can’t automate this sort of test, and even if it is found, it is not assigned a severity of 5 or “showstopper” because it doesn’t immediately disrupt operation of the product. So they can sit unaddressed in a product for four or five versions or more even if privately known. Only an exposure because of a security researcher’s work or a major public incident might push it to the front of the priority list.
All of this discussion of corner cases lays down groundwork for further discussion of the “Internet of Things”. Whenever there are cross-disciplinary approaches (like heavy mathematics and communications, or internal network computing and automobiles) to solutions, there is an elevated risk of incident because of practical and theoretical issues. As the industry progresses, and as the startups generating IoT solution code are dealing with their own corner case issues, and as adoption and acquisitions move forward, IoT technologies will demonstrate on a larger scale that we are not learning from past mistakes.