Native Code Protection and Security
The Mozilla vice president of products announced that Firefox doesn’t need to run native code anymore when it comes to plugins. The idea is called crash protection for it aims to keep the web browser alive when a plugin fails to run correctly. At the same time the magical words about the future being in the hands of (open) web standards and HTML5 are uttered. What does this imply in terms of security? Is there any benefit?
The thought of having more reliable web browsers is certainly tempting. It is also true that overloading the browser with plugins increases the „angle of attack” to the point of stalling or most probably catching some malware floating around on the Web. The message seems to be that seperating vulnerable plugins from the browser doesn’t rule out the exposure by the plugin in question. Even if the plugin is weakly coupled to the browser it still processes possibly untrustworthy data from the network. Your browser may be still alive, but the damage might already be done. Your only chance to avoid being compromised by plugins is to secure their code or not to use them.
Invoking the mantra of HTML5 and standards has become a habit. We already have web standards. There are a lot of web applications out there that rely on the capabilities of naked browsers (such as HTML, JavaScript and a bit of vendor flavours). This is as close as you can get to standards. And yet these web applications have their security problems. SQL and script injection can do damage without native code. HTML5 won’t change that, only proper development and security research can make a difference.