Every year, Gartner designates a select number of companies as “Cool Vendors” in their respective market categories. This year, I’m proud to say that Bromium has joined this elite group and been named as a Gartner Cool Vendor for 2013.
Very cool, indeed. But what does that really mean?
Gartner’s criteria for selection is very clear, and it comes down to 3 specific requirements. Let’s take a quick look at each one and see how Bromium stacks up.
1) Is it Innovative, enabling users to do things they couldn’t do before?
Absolutely. Simply stated, Bromium enables users to enjoy complete Internet freedom, regardless of where they are working. Users can now visit any website, download any document, and open any email attachment without fear of being the victim of a cyber attack.
This unprecedented level of user freedom might cause a bit of discomfort to IT organizations. After all, IT normally applies stringent security controls that tend to restrict or limit user freedom on untrusted networks like the Internet. But Bromium’s innovations eliminate the need for any restrictions, while also strengthening endpoint security. How is that possible? It’s because vSentry automatically creates hardware-isolated containers for each and every task performed on untrusted networks, without any impact on user experience or performance. As a result, vSentry delivers 100% protection against all known and unknown malware, APTs, and zero-day attacks – all without relying on outdated detection technologies.
2) Is it Impactful, enabling greater value to the performance of the business?
As noted above, the ability to effectively – and safely – leverage the power of the Internet is critical to the productivity, growth, and success of every business in today’s global economy. In that context, Bromium’s impact on the business is significant, here’s why. The new generation of users entering the workforce has grown up with the Internet and represents an incredibly valuable corporate asset in today’s Internet-powered enterprise. These users are the innovators of the new enterprise. They understand very well how to leverage every possible application, tool and resource to save time, reduce costs, and deliver maximum value to the business. Bromium empowers these users with the freedom to improve business performance.
In addition, Bromium has a positive impact on IT staff in a couple ways. First, there is less urgency to resolve critical endpoint security concerns – such as Windows vulnerabilities, Java exploits, PDF infections, email attachments, or malicious web content. To be clear, these are all still important challenges that need to be addressed, but they will not impact the security of endpoints where vSentry is deployed. In addition, IT no longer has to deal with desktop remediation simply because vSentry prevents these resources from being infected. Eliminating the need for remediation – which Gartner estimates at about $650 per laptop – can save significant time and tens of thousands of dollars each year in IT operations costs. This obviously has a significant impact on the performance of IT and the bottom-line of the business.
3) Is it Intriguing, has it caught our interest or curiosity over the last several months?
Obviously, we did catch the interest of Gartner, which is why we were selected as a Cool Vendor. But why Bromium? I don’t want to speak for Gartner, but I do know that they do a great job tracking requirements, issues, and pain points among their enterprise clients, while also tracking strategies, products, and innovations from the vendor community. On the enterprise client side, I’m guessing Gartner has been hearing what we have been hearing – endpoint security is fundamentally broken and detection-based security technologies simply don’t work well. Bromium’s approach to endpoint security is not evolutionary; it is truly revolutionary. No other vendor is doing what we are doing and, to the best of our knowledge, no other endpoint security solution provides 100% protection against all known and unknown malware attacks. I can see why Gartner considers that “intriguing.” And it might be why they included this comment in their Cool Vendor report:
“Consider Bromium if your organization is looking for innovative ways to protect against advanced targeted attacks.”
We are grateful to Gartner for recognizing Bromium as a Cool Vendor that is innovative, impactful, and intriguing. Now we’d like to demonstrate these same qualities in your enterprise. If you have not yet experienced the power of Bromium, let’s get started!
Much has been written about whether VDI itself is inherently “secure”. This blog will not attempt to answer that question. Instead I want to focus on how we, at Bromium, view VDI security, and how we can help protect companies that are deploying VDI.
Any VDI security discussion should be two pronged:
- Protecting the VDI desktop
- Protecting the endpoint connected to the VDI desktop
Protecting the VDI desktop
Both non-persistent and persistent VDI desktops are susceptible to zero-day attacks that users unwittingly allow in through e-mail attachments and web browsing. Some may believe that non-persistent desktop infections are easier to remediate in the event of a virus outbreak or security breach because the desktop can be refreshed or rebooted to resume its original state, but there is already evidence that advanced malware is targeting user profiles, which persist even after the desktop has been refreshed or rebooted.
Security-conscious organizations have long used screen scraping as a mechanism to abstract sensitive applications using RDS or XenApp to publish those applications to physical desktops. Those of you who recall the IE6 quandary will remember that publishing an IE6 browser from Windows Server 2003 onto Windows 7 VDI desktops for the sake of legacy web application compatibility was not an uncommon practice. More recently, while developing our product strategy, I encountered several VDI shops that continue to publish an RDS-delivered browser (albeit a current one these days) to their VDI desktops. Why?
In the context of defense-in-depth, there are interesting benefits to publishing a browser running on Windows Server onto a Windows 7 Desktop:
First, most malware is not designed to target Windows Server, or more specifically most malware is written to attack 32 bit Windows. That’s not to say you can count on this as a defense mechanism, especially if the attack is targeted,
Second, if the published browser is compromised, the attack does not propagate to the client. However, it creates a sticky situation: Depending on the malware, it could mean that while connecting endpoints aren’t compromised, their browsing sessions may be.
When I asked these enterprises why they would publish a browser given that it is already a built-in component of the desktop, I received mixed answers:
In the case of persistent virtual desktops, doing so was a nearly universal practice in my admittedly small sample set (three large financial companies, a healthcare provider, and a state agency), because it was easier to abstract the browser away from the desktop image. Simply enough: the browser package needed to be refreshed more often than the desktop image.
If we add non-persistent desktops to the mix, the answer often came back that the published browser was pre-configured with optimal settings to access enterprise web applications.
In any case, short of disabling user access to the internet from a VDI desktop (see “Protecting the endpoint connecting to the VDI desktop” below) , even a perfectly patched and configured browser remains susceptible to zero-day exploits, just as a perfectly patched and configured image of Windows cannot protect itself from zero-days.
vSentry for RDS is designed to protect both VDI desktops and published browsers from APTs and zero-day attacks. It’s the only solution that can protect a published browser not only from malware, but also from cross-site-scripting and man-in-the-browser attacks. Our architecture decouples each browsing activity not only from the desktop, but also from every other browsing activity, such that no site can persist or propagate an attack onto another site. The same goes for document-based attacks: One bad apple cannot spoil the bunch.
Protecting the endpoint connected to the VDI desktop
If it is the case that less than 100% of your users are accessing their VDI desktops from thin clients, then this section is for you. If your users are accessing their VDI desktops exclusively from laptops, then this section is especially for you.
The employee laptop is the primary attack vector into your enterprise infrastructure. A compromised laptop puts an attacker within easy range of your virtual desktop infrastructure. Again, referring back to my days at Citrix – nearly all VDI implementations consisted of at least some (and in many cases mostly) employee laptop access to virtual desktops. If the attacker has compromised the employee desktop accessing the employee virtual desktop, then it is safe to assume that a compromise of the virtual desktop is within reach.
By ensuring that malware cannot ever persist to either local or virtual desktops, vSentry is also protecting the rest of your sensitive information and infrastructure.
Thus it is our position that vSentry and vSentry for RDS together are a comprehensive defense-in-depth security solution for VDI.
But… what about nesting?
While not a new concept, VT nesting is still very much in its infancy. I recently recorded a webinar with Steve Poitras from Nutanix about why VT nesting was an inevitable component of desktop computing. While we currently have vSentry running on vSphere (ESXi 5.1) desktops through VMware’s Virtual Hardware-Assisted Virtualization as a POC – hardware support for nesting is imminent, and so is installed deployment of vSentry directly on VDI desktops.
In a previous post I highlighted recent insights from Gartner on a new approach to security, namely execution isolation for untrusted code or data. I described how the hardware-enforced isolation of individual tasks by the Bromium Microvisor offers the most robust possible protection against malware: To break it you effectively need to break the CPU.
A core issue, highlighted by Neil MacDonald, is that different technologies afford different granularity of execution isolation. At opposite ends of the hardware-isolation spectrum are traditional VMs (each with an OS and its apps), and micro-VMs (each of which contains only a single user task). Neil also highlights sandboxing, which uses software to isolate an executing application, to protect the OS kernel from attack.
In this post I aim to provide the rationale for our choice of a user-task (an activity initiated by the user) as the execution construct that should be isolated, both to maximize security and to deliver a compelling end-user experience.
If you’re a security geek and want the cliff notes: The Microvisor implements a Least Privilege Separation Kernel (LPSK) between untrusted tasks and the desktop OS. It is the only Separation Kernel of which I’m aware that takes advantage of the tiny code-base of a security-specialized hypervisor to dynamically apply Least Privilege [versus statically] at a granular level between tasks within a single running OS instance. It relies principally on hardware-isolation for tasks because this offers the most robust barrier to any attack. Finally, it is the first general purpose Separation Kernel that can protect existing, widely deployed OSes and their applications, and that can be deployed and managed using today’s management tools (SCCM, AD or a security console like McAfee ePO).
Our goal is to identify what execution construct to isolate (OS, application, or perhaps even a thread) in order to maximize security and deliver an optimal end-user experience.
Unfortunately neither hypervisor-based OS virtualization nor application sandboxing can adequately secure an endpoint during execution: (Note: it is not my intention to criticize vendors, their products or their legitimate use cases. This classification is solely from the perspective of their ability to offer run-time protection through isolation, in response to Neil MacDonald’s research note)
- Hypervisor-managed isolation of one or more desktops in VMs on a single PC (eg: VMware Fusion, Workstation, or Player; Windows 8 Hyper-V; Citrix XenClient; Parallels; Moka5) certainly has many valid uses, but each VM is no more secure than a native PC because a hypervisor cannot isolate execution within a VM; moreover virtualization pervades the user experience – the user is conscious of which desktop OS they are using for any activity.
- An alternative approach is to run each vulnerable application in its own VM, and use graphical “tricks” to make the VM appear to be a normal application (eg: Microsoft MED-V (used for app compatibility), Qubes OS, and early versions of Invincea). This approach is complex to manage, and also doesn’t solve the security problem: If my browser VM is compromised when I click on a bad site, then when I navigate to my bank, my session is vulnerable to attack.
- Application isolation is another approach. Sandboxing is frequently used to protect the OS kernel from a malicious or compromised application– for example a browser. Of course in this case the isolation is software based, but let’s assume that it, in combination with other software protection mechanisms are as robust as hardware isolation (One can conceive of application isolation approaches that use VT.
For example, see Microsoft Research Drawbridge which may be relevant in future OSes. But using today’s technology, let’s assume we use every process isolation technique at once: IE and its sandbox on top of an OS improvement sandbox such as Sandboxie, further strengthened by Microsoft EMET (a powerful free ASLR tool) and running on a system with the full complement of legacy endpoint protection).Unfortunately, as my colleagues Rahul Kashyap and Rafal Wojtczuk demonstrated this year at Black Hat Europe and this week at InfoSec Europe, if a malicious application compromises the kernel directly (without needing to jump from user space into the kernel) it can compromise the entire system – bypassing all protection. For example on an unpatched Windows desktop, navigating to a web site that causes the kernel to parse a poisoned font file on behalf of the browser is sufficient. And there is a long and growing list of kernel CVEs.
This is a huge “gotcha” – neither application sandboxes (eg: Adobe, Microsoft, Google) nor OS improvement sandboxes (Invincea, Sandboxie, Trustware Bufferzone, ZeroVulnerabilityLabs) can block such attacks. Once again, this is not a criticism: These are powerful technologies that substantially improve system security, but this attack completely bypasses them, and so they are unable to meet our requirement for rigorous isolation of untrusted tasks.
What can we conclude from this? Well, we must assume that the OS kernel will be compromised by a malicious task, so if we are to isolate its computation, we must also isolate all of its kernel activity. Sandboxing is a non-starter. But VM’s can’t solve this problem either.
In the Bromium architecture, the Microvisor hardware-isolates both user-space and kernel activity of each untrusted task. But note that the moment we start to talk about kernel activity, we need to recognize that a kernel compromise will expose all system resources controlled by the kernel, so somehow we need to extend the isolation to include all task-relevant, kernel controlled resources.
Remember that we need to assume that an attack will occur, and that any part of the system, including the kernel, will be compromised. When this occurs the set of system resources available (visible to, and accessible by) the task must be minimal – and indeed must not permit the attacker to succeed in any way – stealing valuable information, or penetrating into an enterprise network.
We identify the boundaries of a task and the minimal set of resources it needs based on the well understood concept of “Need to Know“, (also called the Principle of Least Privilege). Least Privilege dictates the minimum set of system resources (network, file system, desktop) that any task requires to work correctly: For example, in the context of the browser, a task is an application context defined by a site (its TLD), so each browser tab is a different task.
What resources does facebook.com really need? It needs its cookie, and access to the untrusted web. If the browser tab for facebook.com is compromised (say the user clicks on a poisoned advertisement), we can tolerate loss of the cookie. We can live with the fact that malware will have access to the untrusted Internet. The system will still be safe if:
- The malware cannot see any user keystrokes, mouse input or gain access to the screen (to steal pixels from the display, or display content to the user).
- The malware cannot access any files other than the Facebook cookie
- The malware cannot gain access to any valuable networks or sites (eg: SaaS sites, or the Intranet).
- The malware cannot gain access to any devices (for example – it cannot turn on the webcam)
But what about a user who wants to upload a photograph to Facebook? Dynamic application of Least Privilege is the key to delivering an unchanged, compelling user experience whilst maintaining security. As an untrusted application, facebook.com must only have access to its cookie and the web. But if the application logic of Facebook dynamically requests access to additional resources (eg: user clicks on “upload a file”), the Microvisor can decide to grant access to an additional resource, in a granular fashion- but only under precise policy control (Dynamic LP), and with the explicit involvement of the user, and only for the minimum duration necessary. For example (there are many more, but the key take-away is that we can deliver an unchanged user experience whilst dynamically enforcing LP):
- If the user wants to upload a photo to Facebook, she can select the photo (in the usual way) on the desktop, and then (only) the selected file will be injected into the hardware-isolated task for the facebook.com browser tab.
- If the user wants to download a file, it can be allowed to persist outside the confines of the isolated task, but only if we remember the fact that it is untrusted, so that it can only ever be accessed in another hardware-isolated task.
The Solution: Micro-virtualization and the Microvisor
The Microvisor implements a dynamic, hardware-backed Least Privilege Separation Kernel between untrusted tasks and the user desktop:
- It uses Intel VT to hardware-isolate task execution of both user-space and kernel activity, but unlike hypervisor-based virtualization, it does not need to virtualize device hardware, which is controlled by the desktop kernel.
- Instead, it virtualizes access to all shared system resources in such a way as to enforce mutual isolation of all tasks and the desktop, using interfaces and primitives that are task-relevant. They include the file system, registry, network services, and desktop services such as the clipboard, display, and user input. The isolation is achieved using light-weight “task-level enlightenments” that build on standard OS APIs.
- Execution is non-persistent: all changes (to any system resource) made by a task during execution are saved in an ephemeral, throw-away cache that is discarded as soon as the user terminates the task.
Summary
- Micro-virtualization is the only technology that can dynamically isolate all untrusted activity of an application at a granular level, protecting the system even when the kernel is attacked.
- Its incredible robustness results from hardware-isolated execution, the “throw-away cache” of all changes, and granular, dynamic application of the principle of least privilege to ensure that no data, networks, devices or user activity of value is exposed in the context of untrusted execution.
- Micro-virtualization can be straightforwardly applied to today’s deployed OSes and applications on any modern PC or server.
Bromium Researchers working out of our Geneva, Switzerland office – have found an incredible way to prevent earthquakes. This ground breaking technology will be demonstrated live in the next CERN (Center for Emergency Response Now) meeting. The technology has been labeled – the ‘earth-o-visor’. Below are some details of the technology and excerpts that I managed to get out of one of the discoverers.
Fig1 `
The core technology leverages VT-x (Very Tough) plates that go all the way till the orange color into the center of the earth. Per prior research and several failures on this topic, it practically needed an ARM and a leg to get to the real core. There have been reports of people using AV (Audio Video) tools and some even underwent HIPS surgery in the quest. This technology simply isolates the various earthquake prone components of the earth and ensures that earthlings are protected by preventing the earthquake by isolation. Yes, this breakthrough could mean no more earthquake drills for mankind.
The other great benefits of this technology are that now LAVA eruptions can be controlled just by isolating the threat of earthquakes using the ‘earth-o-visor’. One of the most interesting tools used in this experiment was IDA Pro (Interactive Digger & Analyzer). As per the scientists, this helped them to reach all the way till the most important orange part (as illustrated in fig 1).
Rough illustration of IDA Pro is below (we’re still trying to get the exact specs)
Source: http://www.fatdragongames.com/fdgfiles/sci-fi/hollow-earth-expedition-earth-drill-fdg0034
I had a brief chat with Dr Xbee to congratulate him on this major breakthrough. He simply said: ‘This time it wasn’t the Apple fall that motivated me…. rather I would thank Java for this stunning discovery. I was looking at my Windows, sipping my old cup of Java and that’s when it all happened”
We talked to several experts in the industry and asked what would they call this groundbreaking technology? The most truthful answer so far has been ‘Zen’.
More details are expected to be released on April 1st 2013.
Micro-virtualization is a powerful construct that allows us to defend an endpoint “by design” – by hardware-isolating individual untrustworthy OS tasks using Intel® VT. (If you are unfamiliar with our technology, here is a whitepaper.) The approach is intuitively appealing, but beyond the cool factor, it’s important to be able to explain it in terms useful to a security architect whose goal is to reason about security properties of the system in a more formal way.
As a first step, it is important to place micro-virtualization in the context of existing, well understood isolation technologies.
- Classical OS design implements isolation through separation of untrustworthy user processes from the system kernel, and recent research has focused on improving OS design,
- Sandboxes attempt to retrofit software-based isolation between user space application processes and existing vulnerable operating system kernels, using software.
- Multiple independent operating system instances in VMs can be mutually isolated by a hypervisor, and
- Micro-virtualization isolates individual untrustworthy tasks within a single OS.
Are all Isolation technologies equal? In answer to this question, Neil McDonald of Gartner recently published an analysis and reference architecture that allows security teams to understand and trade off different isolation technologies. This is an important first step in providing a framework for understanding the protection afforded by isolation technologies in general. For example, though sandboxing is well established (it’s just a free feature of many applications), it is also assuredly inadequate against a determined attacker. A hypervisor offers robust inter-VM (inter-OS) isolation on a single device, but can’t protect the VM itself (eg: a virtual desktop) from attack. Moreover interacting with multiple VMs (independent OS instances) is impractical for end-users since it negatively impacts the user experience.
Neil’s analysis enables an architect to understand the security capabilities of each kind of isolation technology and the granularity at which it is applied (for example: process, application, VM, or user task / micro-VM).
Our goal at Bromium is to embrace the ease of use of today’s OSes and applications (and their massive installed base) whilst adding the robustness of hardware isolation to user initiated tasks (delivering granular protection and an unchanged UX).
Crucially, “granular protection” is different from “granular isolation”: Imagine we isolated execution down to the granularity of each individual application thread. If one thread were compromised and elevated its privileges, would the fine-grained isolation help to protect the application, or the system as a whole? It would not: The thread would have access to all resources available to the application. Moreover, it would have access to any files in the file-system and the full set of services offered by the kernel, including privileged enterprise networks and storage. It could modify the SAM, and all sorts of program and system configuration data.
The overall security of the system therefore depends on both the granularity of execution isolation (in micro-virtualization – a task) and the granularity of (the task’s) access to security-critical system resources and data. The architectural construct that we use to reason about security of the latter is the Principle of Least Privilege.
It is a fundamental principle of our design that the granular, hardware-enforced execution isolation afforded by the Microvisor is independent from, and orthogonal to granular application of the Principle of Least Privilege. Without a rigorous, independent design and implementation of each, the security properties of the resulting system would be impossible to understand. Since we have covered micro-virtualization in some detail before, my next post will focus on the application of least-privilege in the Bromium architecture.
Most CIOs that I meet have some sort of plan for BYOD. After all, the C-level execs want to use their MacBooks at home and at work! The idea is so popular that even the Federal Government is trying it.
Superficially, BYOD seems like a win-win: The enterprise saves money on device procurement and support, and users get to choose their device. But in my view the idea is over-sold and all too often organizations fail to understand the true financial implications. Citrix, an avid fan of BYOD, acknowledges that the real win is employee satisfaction. But all too often the BYOD discussion omits the real challenge – security and risk:
“For companies that allow personal devices, most surveyed permit employee access to email (70%) and websites (53%), while few allow access to more sensitive data such as file servers (16%) financial records (13%). Even so, if a cyber-criminal gains access to employee email, this can expose corporate information and cause significant damage… ”
Seeking a practical way forward, many CIOs give the user Hobson’s choice: You’re “Always in or always out”. Unfortunately both models are a sort of three-fifths compromise between empowerment and security, and upon closer examination underwhelm both the CISO and users. In this post I will narrow the discussion to “primary productivity devices” – PCs. (Unsurprisingly, PC management could benefit from models adopted in MDM, MAM, and MIM – but even these are inadequate.)
“Always in” devices are owned, managed, secured and patched by the enterprise, are on-domain, and have Intranet access. They can roam, but only under tight control: Access to enterprise applications is only possible over the VPN. The user does not have admin privileges, data at rest is encrypted, the device has endpoint protection, and web browsing is permitted via the enterprise proxy. When in the office, these devices are NAC-ed and put onto an “inside” VLAN.
An employee owned device is “always out”: The owner has full admin rights, and can use the device for any purpose. She is responsible for support (eg: AppleCare) and keeping the device patched. The enterprise has little say over its presence on the device, which is ideally ephemeral, but rarely so in practice. When the employee brings the device to work, it is NAC-ed and dynamically assigned to an “outside” VLAN: The Intranet, enterprise applications and other critical infrastructure are not accessible except via some form of remote access, such as RDS or VDI. The device is effectively in the DMZ and (from any location) the user can only access enterprise web applications or a virtual desktop/app via an SSL VPN and two-factor authentication. Windows desktops and applications run within the enterprise data center, and are “securely delivered” to the BYO device.
Neither model satisfies the needs of the enterprise or the employee.
“Always in” offers the CISO the most control, but no matter what IT does, the user can easily allow an attacker to compromise the device – for example from a poisoned email attachment or inserting a malicious USB key, or unwittingly checking the news on NBC.com. Attacks on roaming devices using hotel networks are also a significant concern. The device’s privileged access to enterprise infrastructure permits an attacker to quickly penetrate deeper. Rigorous IT controls and device lock-down also make life miserable for the user. Most useful consumer web-apps are off-limits, and there are substantial privacy concerns when accessing personal sites. Personalization is taboo: iTunes and Angry Birds are out of the question.
The “always out” user has to be connected in order to work, and endures a user experience dominated by network latency. And not all applications can be remotely delivered. This approach also fails to adequately protect the user or the enterprise: The user can unwittingly install malware that steals log-in credentials and data (personal and corporate). And remotely accessed virtual desktops are just as vulnerable to a bad click – which invites an attacker into the data center.
Is there a better way? Yes. The Bromium endpoint architecture satisfies stringent security requirements of the CISO and delights the user – whether she is in the office or on the road. I will cover the various aspects of this in a series of future posts.
This week my colleague Rafal and I had fun presenting our latest research on sandboxing, @BlackHat EU, in Amsterdam. We showed how to bypass popular application sandboxes on Windows viz: Sandboxie, BufferZone Pro, Google Chrome and Adobe ReaderX. This is a fun game in general, but we played it a bit differently: We did not spend any time trying to find vulnerabilities in the sandbox implementation. That’s the usual approach, with a different attack surface, and a lot of our fellow security researchers play it regularly (mostly for fun and sometimes for profit). Our approach was focused on leveraging Windows OS kernel vulnerabilities to bypass the sandbox to gain complete control of the system, including the sandbox. We argue that we can compromise any sandboxed application, no matter how good the sandbox architecture or implementation. Several of the sandbox vendors that we notified about the vulnerabilities we discovered were a bit smug, offering us “good luck for the talk” (perhaps implying that we would fail or that they didn’t care, and one did not even bother to respond).
In case you missed the talk (yeah just to avoid the Dutch winter), the summary of the talk is:
- Application sandboxes have a fundamental architectural limitation, they cannot reliably protect against vulnerabilities in the underlying Operating System. So your application sandbox is as secure as the next upcoming kernel advisory from Microsoft.
- Attackers are getting sophisticated; kernel vulns are getting more prevalent. Just last month there were 30 kernel mode vulns patched, ok ok… it might be a slight deviation in the curve, but in 2012 itself there were 25 kernel patches from Microsoft. Kernel interfaces are a huge attack surface and it’s getting interesting there.
Sandboxing is not bad, it’s definitely useful. But, as we just demonstrated, it’s not a useful enough approach to be able to tackle the emerging threat vectors. Last week’s pwn2own contest at Cansecwest conference seems to have used a kernel OS exploit to bypass the sandbox, we don’t have full details yet, but it looks like a neat escape.
Recommendation: Run an application sandbox inside a VM environment – especially if you are a malware pro or an enterprise that cares about its IP. You don’t want be the innocent victim of next Duqu equivalent kernel zero day malware.
The Whitepaper is available here and the slides are available here.
P.S: Although “Sandbox Roulette” was fun (and yes we like winning!); our next stop is launching a ‘Sandstorm’ @InfoSec London next month. Hope to see you there! (nope I won’t comment on the English weather!!)
