Still Dreaming of Perfect Code?

Still Dreaming of Perfect Code?:
Since our launch last week we’ve been swamped with requests for more information about vSentry.  We were thrilled to be included in the Business Insider’s Top 10 Enterprise Disruptors, but I want to point out that in spite of our confidence in our architecture, we would be the last to say that “Bromium Could End Computer Viruses Forever”.
We launched at the Gartner Security and Risk Summit in London, where there appeared to be universal agreement that the “detect to protect” approach of the AV industry has been up-ended by advanced polymorphic malware, and attendees were keen to hear about new ways to bolster their defenses.
I was frequently asked about differences between micro-virtualization and other technologies, which has motivated me to dig into specific tech areas in a series of blogs.  Today we start with sandboxing.  If you want the quick summary, the bottom line is this:  Today you can pick up a sandbox for a song, or easily (ask Oracle)  make your own, but malware breaks out of software sandboxes depressingly frequently.  With a zero-day in hand the malware writer can then easily own the entire system.  You shouldn’t be surprised.  Humans write bad code!  Micro-virtualization will protect you when software sandboxes inevitably fail.

• The single biggest difference between micro-virtualization and sandboxing is that the latter is a software-based approach, whereas micro-virtualization relies on hardware isolation.  This can be stated thus:  “If the software sandbox is compromised (eg: thus), what protections remain?”  For all sandboxes, the answer is “the standard OS protections”.  For micro-virtualization the answer is “virtualization hardware, the Microvisor and standard OS protections”.  More succinctly: software sandboxed applications are a good idea.  You ought to protect them using micro-virtualization.
• Sandboxes aim to isolate an application (typically a process) from other applications and the OS kernel, whereas micro-virtualization isolates tasks from each other and the rest of the system.  A task includes all user space and kernel execution for the isolated code. This is crucial to the vSentry protection model: If malware escapes into the kernel via a zero-day it will still be completely contained, whereas a zero-day escape from a sandbox leads to complete compromise of the system.
• Applications often have to be adapted in some way to run in a sandbox – for example through vendor-specific implementations, installing the application in the sandbox, re-linking or re-packaging the app (eg: App-V, which serves app-delivery needs and is not intended for security).   Micro-VMs can run any application natively – the application / OS interface is not modified in any way.
• Who’s sharing your sandbox? Applications that interact with each other need to be co-resident in the same sandbox, leaving one application vulnerable to a successful compromise of another.  For example a key-logger that compromises the browser will also have access to any other application that cohabits the sandbox, such as the email client.
• Granularity: Sandboxes contain entire applications, such as the browser.  A compromise from one malicious site can therefore follow the user to all other websites visited.  By contrast, micro-VMs are used to isolate arbitrarily granular sub-application entities such as individual sites in a browser, or documents in Word or Excel.   We aim to make it impossible for a single compromised task to compromise any other activity on the desktop.
• The vulnerability of any system is proportional to its code size.  To protect the OS from a malicious process a sandbox must to limit access to the entire system call interface and to any other mechanisms (COM, OLE, clipboard) that can be used for IPC or to gain access to OS services.    By way of example, the Chrome browser counts about 5 MLOC, of which about 1 MLOC are for the Webkit renderer.  The isolation layer between OS and process is of O(1 MLOC).
  
  • More code = more vulnerabilities.  Humans leave bugs. Sandboxing is a dream.
  • Complex code interfaces can be inadvertently broken by OS patches
  • Better sandboxes are typically less general purpose – for example Chrome’s, which will only ever serve the Chrome browser but after 12 years of development is certainly the best
  • More general purpose sandboxes such as Sandboxie are invasive of the user experience, and change OS semantics (eg: saving downloaded files from a browser sandbox session requires the user to specially copy them, and applications that interact need to cohabit the same sandbox).  They tend to have more  limitations than application-specific sandboxes.

vSentry adds a tiny amount of (untrusted) code to standard OS service interfaces (eg: file system filter drivers) and instead relies on Intel VT to do the hard work of isolation: It is impossible for a micro-VM to access any controlled system resource (its files, network services, devices, clipboard) or interact with the user at the keyboard without being stopped by hardware (a VM_EXIT), whereupon the Microvisor is given the CPU to implement mandatory access control.
Perhaps as importantly, the resource view from within the micro-VM is  task-specific and implements the principle of least privilege: The PDF renderer only has one file: the PDF document it needs to render; it can’t turn on the webcam, or access the enterprise network or any enterprise data.
Bottom line:  Humans write bad code, even when they are writing sandboxes.  Sandboxing is a useful approach, but it won’t save you.   Hardware based isolation is the only approach that minimizes the vulnerability surface, and micro-virtualization protects you even when malware escapes and takes advantage of a zero day.