There is a lot of code involved converting types between various languages.

Interoperability is effected by standard bugs like buffer overflows and memory corruption but also three new vulnerability classes:

• Object retention vulnerabilities
• Type confusion vulnerabilities
• Transitive trust vulnerabilities

Object retention

Since an object does not know which other objects are using it, it does not know when to destroy itself. Most often this is done via a reference counter but this is not perfect, leading to using heap data as pointers, double frees, objects not being freed at all.

Issues arise from reference counters rolling over, objects being freed to often or not at all. Also a shallow copy instead of a deep copy can lead to problems. These are all programmatical errors.

Type confusion

In IE variant data types require careful programming, therefore they present an opportunity to attackers. Often this is not picked up by the compiler. It can lead to memory corruption and can be exploitable. This is what happened in the ATL bug . This can lead to e.g. double frees. These issues are also present in ATL and addressed by Microsoft’s patches.

Demonstration #1: An active X control was loaded and passed a persistent data stream which caused a free call to uninitialized data. This is exploitable so shell code was executed.

Demonstration #2: in windows 7 IE8 an array of object was passed in stead of the actual objects. The browser interpreted the array as an object which leads to exploitable error.

Even tough Firefox’ NPAPI is a lot simpler, it requires the programmer to check the data types himself, which is often forgotten leading to the same types of issues.

Trust

Browsers need to deal with a lot more the just HTML these days.

If a browser uses a trusted object A and object A trusts object B which is not trusted by the browser, it is still executed.

Demonstration #3: An object is first loaded but its killbit set and not executed. Then a trusted object is loaded, but it is passed a killbitted persistent object which it will execute. In its turn this object will actually start up calc.exe

Remediation of the ATL issues

Any ActiveX control compiled in the last 15 may have these vulnerabilities in there. ATL2.0 was released in 1997 and ATL 9.0 in 2008. Any ActiveX control based on a vulnerable ATL need to be checked if it is vulnerable, if may need some reprogramming and will need recompilation.

All in all there might be quite a big check of vulnerable controls out there besides the other interoperability scenarios that this talk did not address.

A paper is available at http://taossa.com or http://hustlelabs.com

Quick word on the Microsoft patches

When I asked the guys if Microsoft patches provide a sufficient solution I got an evasive answer. However, one of the demonstration machines auto updated itself yesterday and the demonstration stopped working.

Moxie wrote the tool SSLSNIF is that is able to do a man in the middle attack on  an SSL connection based on this vulnerability to proof to Microsoft that it could be exploited, contrary to what Microsoft said.

Even tough Microsoft and others fixed the vulnerability, the tool is still useful, mainly because people don’t pay attention to certificate warning. Also when the guys that made the fake CA certificate by means of the the MD5 collision use SSLSNIFF to actually exploit is.

But there are more ways to attack SSL then doing a man-in-the-middle attack; SSL Stripping

SSLSTRIP actually attacks SSL before we get there by doing a MitM attack on http. Most https links are not typed, but clicked on or redirected to. SSLStrip watches the http traffic go by and modifies links to https sites to links to http, but it still does the https connection in the backend.

The server thinks is everything is normal because it is receiving valid https requests, the client does not display any warnings, but they are missing lock, but because the user is trained to pay attention to negative feedback and not look for positive feedback, this is not a big issue.

Where do we need to go next?

SSL needs to provide Secrecy, Authenticity and Integrity in order to be effective.

One of the issues is that today there are no people involved anymore with SSL certificates. Just domain validation which is based on a Whois lookup of root of the subject. This provides an email address or phone number to send a token to.

The standard for the DN has totally broken down. Most implementations just look at the CN= part. The CN is stored as a ASN1 string in memory, so they are basically Pascal strings, which means that the actual string is prepended by a byte representing the length. The null character is a valid part of CN string. However if you use the C routine Strcmp() it will actually regard www.paypall.com\0evil.org the same as www.paypall.com.

This bug exists in most web browsers, mail clients, chat clients and SSL vpn solutions like Citrix.

SSLSNIF 6.0 supports this.

Drawback of this attack: It needs to be targeted

Most of these products use NSSto do their certificate validation. If you look at the size and structure of the CN comparison code, there must be a bug in there somewhere.

There is: a certificate for *\0thoughtcrime.org will actually work. This is better then a CA certificate. *~thoughtcrime.org will work as well for some strange issue. As will grouping. CN=(www.paypal.com|www.google.com|www.bankofameric.com)\0.thoughtcrime.org actually works as well.

Also there is a flaw in the code thas actually remotely exploitable: (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\0OVERWRITE).foo.com. And the good thing is, the certificate does not even need to be signed.

Wildcard support is in SSLSNIF as well.

It does fingerprint the clients as well to see if they are SSN clients.

Two measures work against these attacks: Revocations and software updates.

These days most revocations are checked via OCSP. The OSCP response “try later”, the number 3, does not need to be signed. Most SSL implementations will assume a cert is valid if a “try later” rsponse is sent.

This is now also in SSLSniff.

Updates

Most software has an auto update function, e.g. take Firefox or Thunderbird. Unfortunately, these update mechanisms themselves could be a problem. Actually, Firefox/Thunderbird update files are not signed and they totally rely on TLS for their security.

This is also included in SSL Sniff

Stripping the NULL character is not the solution. Some CA’s are vulnerable sitekey.ba\0nkofamerica.com becomes sitekey.bankofamerica.com.

http://www.thoughtcrime.org

When asked, Moxie confirmed that Firefox 3.5 is NOT vulnerable.

moxie@toughtcrime.org

A content security policy, which is specified here, can impose common sense security restrictions on the (active) content of site.

A content security policy can completely kill Cross Site Scripting if it is set to:

1. Require that all javascript is loaded from an external file
2. This file resides at a specified location