Cupfighter.net

Interoperability is everywhere in browsers Java <-> VBScript, VBscript <-> .NET, .NET <-> Javascript, Javascript <-> DOM etc. This interoperability presents a large attack surface, which is up to now where not well explored.

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.