Endpoint
5/14/2013
00:57 AM
Connect Directly
Twitter
Twitter
RSS
E-Mail
50%
50%
Repost This

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

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Spikes
50%
50%
Spikes,
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.
Zuly
50%
50%
Zuly,
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
50%
50%
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
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-3946
Published: 2014-04-24
Cisco IOS before 15.3(2)S allows remote attackers to bypass interface ACL restrictions in opportunistic circumstances by sending IPv6 packets in an unspecified scenario in which expected packet drops do not occur for "a small percentage" of the packets, aka Bug ID CSCty73682.

CVE-2012-5723
Published: 2014-04-24
Cisco ASR 1000 devices with software before 3.8S, when BDI routing is enabled, allow remote attackers to cause a denial of service (device reload) via crafted (1) broadcast or (2) multicast ICMP packets with fragmentation, aka Bug ID CSCub55948.

CVE-2013-6738
Published: 2014-04-24
Cross-site scripting (XSS) vulnerability in IBM SmartCloud Analytics Log Analysis 1.1 and 1.2 before 1.2.0.0-CSI-SCALA-IF0003 allows remote attackers to inject arbitrary web script or HTML via an invalid query parameter in a response from an OAuth authorization endpoint.

CVE-2014-0188
Published: 2014-04-24
The openshift-origin-broker in Red Hat OpenShift Enterprise 2.0.5, 1.2.7, and earlier does not properly handle authentication requests from the remote-user auth plugin, which allows remote attackers to bypass authentication and impersonate arbitrary users via the X-Remote-User header in a request to...

CVE-2014-2391
Published: 2014-04-24
The password recovery service in Open-Xchange AppSuite before 7.2.2-rev20, 7.4.1 before 7.4.1-rev11, and 7.4.2 before 7.4.2-rev13 makes an improper decision about the sensitivity of a string representing a previously used but currently invalid password, which allows remote attackers to obtain potent...

Best of the Web