MS09-056 addresses two vulnerabilities that affect how the Windows CryptoAPI parses X.509 digital certificates. Applications on the Windows platform as well as Windows components such as the WinHTTP API can call into the CryptoAPI which provides cryptographic services to validate digital certificates. Internet Explorer, for instance, uses the CryptoAPI to parse and validate the certificate of remote web servers while browsing.
Digital certificates can prove that one peer in an SSL connection is who he claims to be. They are signed by a trusted, independent third party known as a Certificate Authority. Most often used to protect communications to web sites, they are also in common use to protect e-mail communications or B2B connections. The X.509 standard describes what information can go into a certificate and uses ASN.1 (Abstract Syntax Notation 1) to describe the format of the data. Object Identifier or OID is the ASN.1 type used to identify specific elements of the certificate such as an algorithm or attribute type. For example “2.5.4.3” is the OID that identifies the “Common Name” or “CN” string field in a certificate.
Addressed in this security update are a null truncation vulnerability and an integer overflow condition in ASN.1 parsing. Both of these vulnerabilities were discovered and presented by Dan Kaminsky at the BlackHat security conference in Vegas at the end of July of this year.
· CVE-2009-2510: Fields in the certificate’s subject name (such as the ‘Common Name’ or ‘CN’ field) which contains a NULL character in the string will cause the CryptoAPI to parse only the portion of the string prior to the NULL character. However, the certificate may have been issued to the organization / domain that comes after NULL character in the string.
· CVE-2009-2511: In a certificate, each Object Identifier (OID) is stored as a sequence of integers but is converted to a string by CryptoAPI when parsing a certificate. . The ASN.1 standard does not specify a maximum value for integers, but CryptoAPI assumes integer components of an OID can be safely parsed into a 32 bit integer in memory. A specially crafted OID number may result in an integer overflow condition that could cause it to be parsed in a way that allows the OID number’s data to replace the data for the previously encountered OID. This can cause the Certificate Authority and Windows to parse the certificate differently. This vulnerability can be exploited in those cases where the Certificate Authority ignores the specially crafted OID and agrees to sign the certificate, whereas the Windows CryptoAPI does parse the crafted OID.
Both of these vulnerabilities have an impact of spoofing, which means that an attacker could use them to fraudulently spoof the identity of another legitimate server on the internet.
This sounds quite serious and it is. However, it is important to take into account that the effort required in setting up such an attack is extensive. In order to exploit this issue in a web browsing scenario an attacker must successfully complete the following steps:
1. Convince a certificate authority to sign a rogue certificate. This would need to be a Certificate Authority that is present in the Root Certificate store of the Windows machine;
2. Execute a successful man-in-the-middle attack that hijacks the connection from a vulnerable client to a server and present the certificate to the client, e.g. via a DNS spoofing attack or via ARP cache poisoning on a local subnet.
Leveraging an attack which abuses these flaws is not trivial but cannot be excluded. We do believe that the threat of these attacks is significantly mitigated by these requirements posed on the attacker. However, the TLS Handshake Protocol (RFC 2246) makes two security promises that are violated by these vulnerabilities:
· The peer’s identity can be authenticated;
· That no attacker can modify the communication without being detected by the parties to the communication.
As this vulnerability shows the potential of breaking this security promise, we consider it important to address these issues and are releasing this security update. We recommend that customers install them at their earliest convenience.
Updates to the CryptoAPI affect a vast number of applications that run on the Windows platform and these require very thorough and stringent testing prior to release. For this specific update our engineers looked specifically for applications that may have been affected by the unique changes made to this API and performed very detailed and specific interoperability testing. Quality of security updates is paramount to Microsoft which for the CryptoAPI often results in a fairly long test cycle.
During the development of these security updates Microsoft has continued to evaluate the threat environment to assess the risk these vulnerabilities posed to our customers. Certificate authorities that are included in the Root Certificate store on Windows are all required to meet the requirements of the Microsoft Root Certificate Program. A list of the third-party certification authorities (CAs) that are trusted by Microsoft and whose root certificates are distributed via the Root Certificate Program can be found in KB article 931125. During the development of these updates the MSRC has worked with certificate authorities to ensure that their systems were also hardened to help prevent signing certificates that may have attempted to exploit these vulnerabilities.
Thanks to Gavin Thomas and Robert Hensing from the MSRC Engineering team and Kelvin Yiu from Windows Crypto for their technical investigation into these two issues.
-Maarten Van Horenbeeck, MSRC Program Manager