Is this Google's ActiveX Disaster?

Share

I remember very well the days in the mid 1990s when it became clear that Microsoft's ActiveX technology, which grew out of OLE, a way for creating compound documents, was essentially the world's greatest browser malware construction kit.

Since then, ActiveX exploits have probably caused more harm in the Windows world than any other aspect of Microsoft's flawed platform. So it is with some consternation that I find that Google seems to have learned nothing from history:

Native Client is an open-source research technology for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps. We've released this project at an early, research stage to get feedback from the security and broader open-source communities. We believe that Native Client technology will someday help web developers to create richer and more dynamic browser-based applications.

It's great that Google is making its Native Client open source, but the following does nothing to alleviate my concerns about the possibility that this simply means that, unlike Microsoft's closed-source ActiveX, Native Client is an *open-source* browser malware development kit:

Our approach is built around a software containment system called the inner-sandbox that is designed to prevent unintended interactions between a native code module and the host system.

The inner-sandbox uses static analysis to detect security defects in untrusted x86 code. Previously, such analysis has been challenging due to such practices as self-modifying code and overlapping instructions. In our work, we disallow such practices through a set of alignment and structural rules that, when observed, enable the native code module to be disassembled reliably and all reachable instructions to be identified during disassembly.

With reliable disassembly as a tool, it's then feasible for the validator to determine whether the executable includes unsafe x86 instructions. For example, the validator can determine whether the executable includes instructions that directly invoke the operating system that could read or write files or subvert the containment system itself.

I can't help feeling that Alan Turing would have had something to say about this approach....