Blog

Browser vendors such as Microsoft and Google invest significant thought and resources into making sure that the browsers are secure from exploitation, from starting with a secure architecture to integrating specific security mechanisms. So, can you rely on this built-in browser security?

Browser Security

Browser security is a general category that includes the need to protect from a variety of very different types of attacks. Some aim to steal data entered into web pages; others try to attack the endpoint itself.

In the latter group, of endpoint attacks, probably the most common method is using various methods of social engineering to get users to intentionally authorize downloading and running files that are seemingly benign but actually malicious. These include, for example, URL phishing and fake browser updates. User vigilance, combined with browser mechanisms that assist users in identifying malicious sites, such as site checkers and certificate verification, can significantly reduce the occurrence of these attacks, although relying on users is always a risky business.

However, even without any special authorizing action on users’ part, browsers’ exposure to the internet creates a potential channel for code infiltration. Web content can contain malicious code – whether from an intentionally malicious site, or from a legitimate site that has been compromised by cyber criminals. When web content is displayed in your browser, it’s running on your computer, creating the potential for attacking the computer in a multitude of ways.

Browser Hardening

Browser vendors are aware of this risk as well. To combat it, for more than a decade browsers have employed sandboxing techniques to isolate various parts of browser architecture from the operating system and from other parts of the browser. Specifically, the processes that render and run content are separated from the processes that are authorized to access parts of the operating system.

For example, here’s Chrome’s process architecture, with the various processes’ authorization levels:

Additionally, to prevent web pages from affecting one another, concurrent tabs or frames from different sources are isolated from one another (Site Isolation).

Vendor Sandbox Vulnerabilities

However, these methods are not foolproof. Vulnerabilities in browser code, that could be exploited by attackers, are regularly identified. The vendors fix and patch their software, with varying degrees of regularity; but invariably additional ones are discovered.

Here’s an example that affected Google Chrome and Chromium-based MS Edge. As recently as March 2020, a vulnerability in the communication channels between browser processes was discovered. Exploiting this vulnerability could have enabled attackers, once they compromised a sandboxed process, to ‘escape’ the sandbox by compromising an unsandboxed renderer process, potentially gaining control of sensitive computer resources. The vulnerability has since been eliminated.

So, relying on browser vendors for security is a game of Russian Roulette – it should be fine most of the time – assuming you keep your browsers up-to-date with latest vendor security patches – but you don’t want to find out when it’s not. And that’s even without considering downloads, which as we mentioned at the outset pose a completely different set of security challenges.

Taking Responsibility

So is the situation hopeless? Not at all. Instead of relying solely on browser internal security, wrap the whole thing – processes and downloads – in its own sandbox, also known as a virtual container. This is exactly what the BUFFERZONE agent does. With BUFFERZONE, browsing sessions are kept in a virtual container, along with anything saved or downloaded, protecting the endpoint and trusted resources from any potential threats. Contained browsing sessions and applications cannot reach the native endpoint or organizational resources such as an intranet; those are accessed only by uncontained browsing sessions and applications, which can’t have accessed untrusted sites.

The advantage of this approach is clear: When malware strikes, no matter how new it is and what evasion techniques it implements – it cannot cause any damage to native endpoint or organizational resources. And, the container is periodically emptied, so even there malware can’t last.

Sources

Issue 1062091, on chromium.org, opened March 17 2020

Tim Becker, Cleanly Escaping the Chrome Sandbox, on theori.io, April 20 2020

Anonymous Google doc, retrieved May 19 2020