Climbing Mount Never Rest: Features vs Security in Browsers

Author: No Comments Share:

In a recent post on ZDNet, Larry Seltzer makes the case that browser security has peaked, and argues that “that’s probably a good thing”.  Browser security may well have peaked, but it’s definitely not a good thing. Adding new features can easily make it decrease, and it isn’t great to start with.

Seltzer’s argument is based on the observation that the addition of new security features has declined in browser releases over the last few years – across all major browsers – and points out the absence (other than the addition of a JavaScript Crypto API for DRM, auth and other app level use cases) of new security features in IE11.  He argues that IE is probably the most secure browser on the market.   So far, so good.

IE11 adds support for the oft vilified WebGL standard (security white-paper), which enables client gpu-assisted rendering of complex graphical elements, including games.   Since graphical languages are basically programming languages, and require the client device to hand the graphics driver to the browser with no understanding of the “program”, you can see why Microsoft for a long time pushed back on the inclusion of WebGL in the browser.   (As an aside, client-side graphical command remoting is a hot issue in the desktop virtualization arena, where Citrix and Microsoft vie to outdo each other in terms of the fidelity of hosted Windows apps/desktops.  Fortunately in that arena there is an explicit trust relationship between the client and the server hosting the desktop/app.)  To help protect against possible WebGL based attacks, Microsoft has added client-side sandboxing / sanity checking to its graphics drivers to mitigate the risks of this new interface.  However, this is an area of great complexity, and the new interface, though presumably carefully tested by Microsoft, has yet to be fuzzed by malware writers.   So I put this very decidedly in the category of “let’s wait and see”.

Seltzer’s argument is deceptively simple: In a nutshell, the vendors aren’t adding many new security features, and browser-based attacks are harder, so presumably we’re all OK?  This is wrong for several reasons:

Browser vendors may well have done what they can to sandbox the browser, but that does not mean that the browser is a secure gateway to the scary web, or that users are safe.  There are limits to the protection that software can offer, and they continue to add new features with large code bases:

  • An attacker can bypass the browser by attacking the kernel directly, or escaping the sandbox from user-space via a vulnerable Windows service.
  • The code surface of the browser and its plug-ins is huge.   New code means new vulnerabilities, which will be found and exploited.
  • In the specific case of IE, Flash is incorporated into the browser so that it can auto-update (making it more secure), but this exposes the browser to a massive third party code base and its latent vulnerabilities Here are some recent exploits for IE10 on Win8, which on their own utterly contradict the notion of Browser security completeness. Today the easiest (admittedly reliable) way to infiltrate into the enterprise is via Web browsers and emails. This is not just because of the ubiquity of Internet Explorer but also because of the large attack surface of browsers in general and the fact that all users need to run untrusted code every time they surf the web.
  • To make things worse, scripting engines of browsers provide ample scope for exploit obfuscation and evasion to bypass traditional signature/detection based defenses, making it the best target ROI for malware deployment.
  • Every browser version is touted to be ‘better’ and ‘more secure’ than the previous one – which in some cases is true. Microsoft undoubtedly is doing a great job in plugging off older ‘traditional’ exploitation vectors. However, we should not forget that it’s a war of adding functionality, backward compatibility and security in a vastly complicated code base. They are climbing their own ‘mount never-rest’.   Here, for example are some stats for IE9 and IE10.
  • Java, Java, Java.  Enterprises require legacy JRE support on the client because server-side applications impose version compatibility requirements (and you gamers also need Java to support Minecraft). Even the latest Java releases have had issues. Malware that breaks the JVM bypasses the browser sandbox directly.
  • The user can still trivially download, save and execute malware or poisoned content using the browser, leaving protection up to your AV suite (good luck!), the user,  or IE protected-mode and UAC – otherwise known as “click to edit/trust/install/run…” and “do not show me this warning again..”
  • The clipboard can be used to transfer attacks from unsafe content in the browser to other applications.

The browser vendors are doing good work – perhaps as much as one could ask for.   But you’re still vulnerable – as Seltzer acknowledges: “Obviously users still get hacked through browsers, but that’s a different sort of problem, usually involving social engineering and no real software error. It’s just another way of saying we’ve done what we can securing the browser; now we have to secure the user and that may be impossible.”  But this is not a good thing.

It is impossible to train the idiot user out of me.  Worse, my browser cannot secure me and the OS is vulnerable.   There is only one way to radically increase system security given the inevitability of an attack: massively decrease the attack surface of the end point using micro-virtualization.   This is the only way to protect the end point from the idiot in me.

 

 

Previous Article

The latest TDL4 and CVE-2013-3660 exploit enhancements

Next Article

Hey Adobe, hackers have access to your Source Code!

You may also like