Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


12:57 AM
Connect Directly

Is Application Sandboxing The Next Endpoint Security Must-Have?

Virtualized containers expected to catch on in the enterprise, but the technology has its weaknesses, too

With the onslaught of zero-day attacks continuing to increase the barrage of unanswered threats against endpoints, there's a growing contingent of security advocates championing the addition of a virtualized container layer in the endpoint security mix. Analyst predictions are rosy for the virtual containerization market to grow as a security niche and enterprises are certainly clamoring for a way to help them beat the signature-defense hamster wheel.

But this containerization approach, also referred to as application sandboxing, has some researchers pointing to what they call a potentially fatal flaw: kernel vulnerabilities.

"Essentially if an application can pull the kernel into stumbling on a logic bug in the kernel itself when the kernel is working for the application, you can compromise the kernel directly and thereby step over and directly bypass any form of sandbox protection," says Simon Crosby, co-founder and CTO of Bromium, which took the wraps off such a bypass earlier this spring at Black Hat Europe. Now Crosby says the firm plans to release new proofs of concept at Black Hat USA in August. "And, by the way, it's a very large and rapidly growing list of kernel vulnerabilities, a huge footprint of code."

That nevertheless may not deter the market for virtualized containers, which essentially operate under the principle of reducing the attack surface within the endpoint.

[Why does SQL injection linger? See 10 Reasons SQL Injection Still Works.]

"The whole notion is machines get infected when users interact with untrusted content and so the container essentially segregates the large attack surface that the operating system presents to untrusted code from the untrusted code," says Anup Ghosh, CEO of virtualized containerization vendor Invincea, who points to recent Gartner predictions that the virtualized container market will grow from less than one percent of the enterprise market today to 20 percent by 2016.

According to Gartner analyst Neil MacDonald, the security market is due for a renaissance in sandboxing and containerization. "The idea is compellingly simple: define a core set of OS and applications as 'trusted,'" he says. "Then, if you need to handle a piece of unknown content or application, by default treat it as untrusted and isolate its ability to damage the system, access enterprise data and launch attacks on other enterprise systems."

Interestingly, even Bromium could be lumped into this same category as Invincea, as the company segregates application processes into what it calls microvisors. According to Crosby, Bromium differentiates itself through its use of hardware isolation.

"Sandboxing just isolates the application user space code. [It] assumes that the bad stuff is executing as an application within the context of an application, when in fact, the bad stuff could be executing within the kernel anyway because the kernel was doing some work for the application," he says. "Fundamentally, we have a completely new approach which isolates all kernel activity on behalf of the tasks [using] hardware to isolate instead of software."

But Ghosh contends that Bromium uses a virtualized containerized approach as well, and that for all of its hardware claims it is still a software company.

"They don't like to talk about it, but they ship as software. They do use the what are called the VT extensions in to the Intel chip set," he says. "People who work in virtualization understand that the VT extensions are a hardware performance upgrade; it's an extension of the chipset language to optimize performance for virtualization. But they're using that to try to convince the market that they have hardware-based security."

As for the vulnerabilities discovered by Bromium, Ghosh doesn't deny the imperfection of the sandboxing approach. Vulnerabilities are part of any security architecture, he says.

"Architecturally, it's a sound approach. Is it infallible? No. Will there be vulnerabilities that get through our approach? Probably," he says. "And that's OK, because the customers sort of expect that you'll have breaches of different layers of security and that's why you have multiple layers."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Ericka Chickowski specializes in coverage of information technology and business innovation. She has focused on information security for the better part of a decade and regularly writes about the security industry as a contributor to Dark Reading.  View Full Bio


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
5/16/2013 | 9:36:08 PM
re: Is Application Sandboxing The Next Endpoint Security Must-Have?
I see four different forms of sandboxing right now:

1.Microvisor, runs applications within the host OS, but within simulated boundaries, supported by processor instructions. This is what Bromium does, yeah?

2.Type 2 Hypervisor runs in a virtual OS container, but not on bare metal, instead. Invincea, Panda, etc use this right?

3.Type 1 Hypervisor (https://en.wikipedia.org/wiki/... basically running each application in its own OS within a virtual machine on a bare metal hypervisor. Pretty good security, but terrible ease-of-use.

4.Full hardware separation, with a network and firewalls in between the client and the application. This is what Spikes does. (www.spikes.com) for browsers today, with awesome ease-of-use.
User Rank: Apprentice
5/14/2013 | 2:53:54 PM
re: Is Application Sandboxing The Next Endpoint Security Must-Have?
You have hit the nail on the head about the weaknesses of sandboxing. When the sandboxed application can attack your kernel because it is running with it, the sandbox protections are easily bypassed. But the future of containerization goes way beyond simple application sandboxing.

My startup, Light Point Security, is also in the security-through-isolation space, but instead of application sandboxing, we use server-based virtualization to separate the application from the endpoint. We actually run the contained application inside a one-time-use virtual machine that runs on a server. And we take it even further by isolating that virtual machine within a second virtual machine.

So security-through-isolation will definitely become the standard in endpoint security, but only when the isolation is absolute. Letting an isolated application share resources and have direct contact with the operating system is still risky, because it gives attackers a way out of the containment.
Ahmed Masud
Ahmed Masud,
User Rank: Apprentice
5/14/2013 | 6:59:39 AM
re: Is Application Sandboxing The Next Endpoint Security Must-Have?
Virtualization is really not the answer to edge-security because all that does is simply add another wedge between the back-end and the edge.

The only way to really safeguard against kernel-vulnerabilities is to put in a verifiable and mathematically immutable reference monitor into the core kernel constructs. So that the user-space <=> kernel-space interactions are only trusted through a well defined interface and that the rest of the kernel and all of the user-space is not to be trusted with the data-exposure.

See figure 1 below... If you have a vulnerable environment who cares if your Hardware is actual Hardware or "Soft Hardware" ; Actually there is arguably a chance that introducing a new kernel (namely the VMM kernel) one may make the situation worse. It's a second kernel and unless it's fully verifiable and a reference monitor for all app <=> kernel interactions ; we are mmm back to square-1

Just my 2- worth
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.