Chrome Perfected: Fast, Massively Secure and Gloriously Private (1/2) [feedly]

----
Chrome Perfected: Fast, Massively Secure and Gloriously Private (1/2)
// A Collection of Bromides on Infrastructure

Bromium or Chromium?  The right answer is both.  Chrome users have an almost religious passion for their browser, whose rapid ascent threatens to eclipse IE.  Bromium's micro-virtualized Chrome substantially surpasses Google's own vision, delivering fast, massively secure and gloriously private browsing.    Micro-virtualization delivers superior security, and its granular, task-centric isolation preserves the Chrome user experience while rigorously protecting user privacy – something that no browser has ever achieved before.

I thought Chrome was perfect already?

If you happened to be laboring under the illusion that Chrome is secure, or naively assumed that Google embraces your aspirations to protect privacy, then you might want to refer to the vulnerability and update history for Chrome, and the Bromium Labs team's assessment of Chrome's current (in)security.

Our customers wanted us to massively improve Chrome's security and to add options for user privacy that give users and corporations alike the choice to avoid the prying eyes of advertisers (including Google, Yahoo, and Facebook whose business models depend on violating "do not track" settings) and other organizations that track user activity online.

As we set about our task, we realized that preserving the Chrome user experience is sine qua non. Chrome is loved for its speed and responsiveness, its seamless access to Google services, SSO and the increasingly "app-y" user interface, and the perception of better security. But users everywhere are increasingly concerned about online privacy – an area where Google has repeatedly let them down.   

Fast, massively secure and gloriously private: Tall orders indeed – but we are proud to have delivered what we believe to be the world's most secure and private browsing experience to Chrome (and, of course, to IE).

In this post I want to tackle the intimate entangling of browser user experience and security to show how micro-virtualization is the only way to comprehensively secure the browser while delivering an awesome user experience and providing real-time, accurate attack intelligence.   In my next post I'll explain how we use micro-virtualization to hardware-enforce privacy – an industry first for any browser, and one that Bromium also delivers to other browsers.

Browser UX is inseparable from browser security

We want to bolster Chrome's security while preserving the UX and delivering complete attack intelligence.

Chrome executes each render task (eg: a URL entered by the user) that will appear in a browser tab in a de-privileged, sandboxed renderer to boost security.  It uses multiple concurrent renderers to improve performance and reduce the impact of crashes, effectively using the Windows scheduler to achieve parallelism across multiple tasks.  It load-balances URLs across renderers, so in a browser with many open tabs, many different sites may, over time, share a single renderer.

Consider two attack scenarios:

1. If an attacker compromises the browser renderer but is confined by the sandbox, he gains access to all state (all sites) that share the same sandboxed render process, as well as to persisted browser state – cookies for all sites – including session cookies for all sites to which the user is currently logged on.
2. If the attacker bypasses the sandbox he gains access to all of Windows and can easily disable all endpoint protection software, steal files and gain access to any networks and sites to which the device has access.

In both cases (assuming traditional AV-style detection) neither the user nor IT will be any the wiser.

What's the risk of compromise? Small, but not insignificant.  The Chrome sandbox can be bypassed and cannot  fully protect a vulnerable endpoint.  Malware can escape containment; alternatively (like every security technology that depends on the integrity of the OS kernel) the sandbox can be bypassed by malware that directly targets a vulnerability in the OS kernel.

We want to make Chrome robust while at the same time ensuring that IT is given accurate alerts when the endpoint is attacked.  Perhaps, as some recommend, we should consider sandboxing the entire Chrome browser itself in a second, security-focused sandbox that detects malware that breaks out of the browser sandbox?

Unfortunately, double sandboxing fails to improve security:

• If only the browser is compromised (case (a)) malware still has access to all browser state including sites and their session cookies, as well as to all networks to which the endpoint has access.  An attacker can easily follow the user between sites, steal credentials and launch cross-site scripting attacks.
• Chrome already incorporates one of the most robust sandboxes.  Adding another sandbox doesn't improve security.  There is a wealth of peer reviewed research, byleadingsecurityindustryresearchers that documents the limitations of layered sandboxes.  Malware can simply bypass both sandboxes at once by

o    Compromising a vulnerable Windows user-mode service, or

o    Compromising the kernel directly via a kernel zero-day.

• Worse still, there is no way to know if the browser or OS has been attacked other than using traditional AV/detection-centric tools.

Moreover, double-sandboxing the browser impacts the user experience so badly that it is unusable in practice:

• If the security sandbox detects an attack (eg: using VirusTotal), the only remedy is to shut down and restart the entire browser including all open sessions/tabs.  Any unsaved entries made by the user will be lost.  On browser-restart the user will have to re-enter credentials and try to salvage their sessions.  This is completely unworkable for any browser activity other than reading.
• The reliance on detection means that an inevitable false alarm results in the browser shutting down arbitrarily, once again ruining user productivity.
• A failure to detect a real attack that might have been contained by the sandbox leaves malware active in the browser where it can steal keystrokes and data from any site, hijack session cookies to gain access to remote sites and use the enterprise network.  The only way out is to artificially restart the browser at regular intervals, with the same UX challenges.
• Finally, since double sandboxing causes the browser to behave differently, access to trusted Intranet and SaaS sites requires the use of a separate browser to make sites work correctly.

Micro-virtualization to the rescue

By independently micro-virtualizing each top level domain (each tab in the Chrome browser) we achieve much more granular isolation than Chrome offers itself.   This gives us all of the benefits of concurrency, and hence great performance, because each micro-VM is independently scheduled.

From a security perspective, a micro-VM offers a barrier that is many orders of magnitude harder to break than the Chrome sandbox.  Moreover each micro-VM isolates both kernel and user-space execution for each browser tab – imposing for the first time ever a hardware barrier between malware and a vulnerable OS kernel.  Finally, since each micro-VM is independently monitored by a "task flight recorder" for proof of malicious activity, we are able to narrowly and precisely record its activity and trigger real-time alerts – for a single TLD.  If malware does execute in a micro-VM, it will be identified, without relying on traditional detection.  As importantly, from the user's perspective, if a tab in the browser is closed because LAVA detects malware, no other tabs are affected.  Malware in a micro-VM cannot gain access to browser state, to the state of other tabs, or to cookies that are not available to the TLD isolated in that micro-VM.  It cannot gain access to the corporate Intranet or to high value SaaS sites.  It cannot access files in the desktop file system, and is completely defeated before being (a) automatically remediated when the user or system closes the tab and (b) its entire forensic execution trace is uploaded in real-time to alert IT of the attack.

Next up – privacy.   A topic of great concern to all of us – at work and play.

----

Shared via my feedly reader

Sent from my iPhone