Endpoint security via
Application sandboxing and virtualization:
Past, present, future
Rafal Wojtczuk [email protected]
• We will talk mostly about securing Windows client systems
• Application sandboxes
• Sandboxie
• Chrome sandbox
• Virtualization-based sandboxes
• Qubes OS
• Bromium vSentry
Bromium Confidential
What is a sandbox?
• Environment designed to run untrusted (or exploitable)
code, in a manner that prevents the encapsulated code
from damaging the rest of the system
• The aim of a sandbox is to isolate threats
Protection by isolation, not detection
Bromium Confidential
Why we need sandboxing?
• Infeasible or too expensive to write a bug-free complex
• Many approaches (AV, HIPS, NIPS) have limited
Particularly against 0days
• Containing a malicious code in a jail is doable
• How effective?
Bromium Confidential
Types of application sandboxes
• Type A: OS enhancement based: Sandboxie, Buffer Zone
Pro etc.
• Type B: Master/slave model: Adobe ReaderX, Chrome
Bromium Confidential
• Example: Sandboxie (available since 2006), BufferZone
• Custom kernel driver modifies Windows behavior, so that
change to protected system components is prevented
• Use cases: Most of such sandboxes are used for controlled
execution of applications
• Sandboxie is widely used for malware analysis
Bromium Confidential
Application Sandbox Type A
Bromium Confidential
Architectural Discussion: Type A
• There is a lot of kernel
interaction that the
sandbox needs to allow
for applications to work
as designed
• It relies on the
assumption that OS
kernel is not
• The sandbox cannot
protect against malicious
kernel mode malware
• Example: Google Chrome (available since 2008), Adobe
Two processes - master and slave, talking over IPC
Slave is confined using OS access control facilities
Master mediates access to resources
Use case: protect the application from exploitation
Google Chrome and Adobe Reader are popular
applications mainly for web and content rendering
Bromium Confidential
Application Sandbox Type B
Bromium Confidential
Architectural Discussion: Type B
• Master has smaller
codebase, the point
being – it should be
tougher to exploit it
• Slave has a bigger attack
surface that needs to be
‘brokered’ by the master
• Slave still directly
interacts with the OS
Kernel – the attack
surface is limited but far
from zero (win32k.sys)
App Sandboxes: Important Points
• Application sandboxes are fundamentally vulnerable to
kernel mode attacks
The sandbox is entirely bypassed, not penetrated
Layering sandboxes doesn’t help
• The attack surface of commodity OS kernels is large, with
no reasonable hope of securing them
Is this a problem?
• Windows kernel issues are discovered increasingly
25 CVE items for Windows kernel in 2012
30+ CVE items in the first 3 months of 2013
There have been targeted attacks like Duqu that have
targeted kernel vulnerabilities
Cansecwest 2013 Chrome sandbox bypass by MWR Labs
used two stage exploit
First compromise the slave
Then compromise the kernel
• Yes… it’s a big problem!
Bromium Confidential
Exploit: MS11-087
User Mode Exploitation
• Type A and Type B do not
restrict network
connectivity for a
sandboxed process.
• The exception to this rule is
Google Chrome that has
been hardened to restrict
TCP/IP networking in case
the renderer got exploited.
• All vulns in these services
are a sandbox escape
• Even properly functioning
code can be abused
ALPC Ports
• ALPC ports [12] are a low-level mechanism used for
interprocess communication on the Windows OS. Again,
many Windows services listen on ALPC ports; if a
sandboxed code can connect to these services, it can
attempt to exploit a vulnerability in it.
• Chrome sandbox documentation correctly states that the
sandboxed process cannot obtain new handles to almost
all existing interesting objects, including ALPC ports.
However, it is not enough – care must be taken to not leak
important handles from the pre-sandbox process state into
the sandbox.
Bromium Confidential
What are the alternatives?
• Wrap the OS in a sandbox such that OS (and other
application) vulnerabilities are nonfatal – this can be
achieved using a Virtual Machine based environment
Bromium Confidential
First approximation – standalone VM(s)
• Just do unsafe activities in a standalone VM
• Manageability problems
• Ultimately, VM will get dirty
• How about using many VMs?
• Managing multiple OS images is painful
Bromium Confidential
Virtualization-based sandboxing challenges
• Manageability
• Performance
• Hypervisor and supporting environment is still an attack
vector, arguably small enough to be defensible
Security vs features tradeoff, e.g. GPU virtualization
Bromium Confidential
Qubes OS (available since 2010)
Bromium Confidential
Qubes OS main features
• Based on a bare-metal hypervisor (Xen)
• All user applications run in “AppVMs”, lightweight VMs
based on Linux – one VM per each “role”
Qubes GUI virtualization presents applications like if they
were running locally (aka “seamless” mode)
Networking code sand-boxed in an unprivileged VM (using
Centralized updates of all AppVMs based on the same
Disposable VMs
Bromium Confidential
Qubes OS deficiencies
• Requires some discipline/training from the user:
• To perform each task in the proper AppVM or disposable VM
• To manage files scattered across VMs
• Using off-the-shelf multipurpose large hypervisor
• Vulnerable to “sysret” vulnerability, CVE-2012-0217
• On the other hand, very careful to introduce as little supporting
privileged code as possible, good
• Linux focused, limited support for Windows VMs
• Using type 1 hypervisor means deployment issues
Bromium Confidential
Bromium vSentry
Bromium Confidential
Bromium vSentry main features
• Available since 2012
• For Windows, based on type 2 hypervisor (derived from
Easily deployable – just install .msi file
Mac OSX version almost ready
• Each instance of application runs in a separate VM
• No need for the human to be involved in VM management
• Possible due to ultra-optimized VM creation time
• Heavily customized/stripped hypervisor
• By design, NOT Vulnerable to “sysret” vulnerability, CVE-2012-0217
• Many enterprise-friendly features
• E.g. transparent support for web proxies that require NTLM authentication
Bromium Confidential
Bromium vSentry current deficiencies
• No support for dedicated networking VM
• … yet
• In comparison with Qubes, more supporting privileged code
• Still managable from security viewpoint
• Ultimately, at least partially solvable by using Intel Trusted Execution
technology and deprivileging the host
Bromium Confidential
• Will someday virtualization-based sandboxing become
omnipresent (well, at least as Chrome sandbox currently)?
• Some features are unique
E.g. vSentry sandboxes MS Office applications
• The resilience against kernel exploits should be relevant
• Any chance for secure Windows kernel soon?
• Some mitigations, e.g. SMAP, are interesting, but not a silver bullet
• Functionality concerns
• Intel will provide hardware-assisted GPU virtualization some day
• So yes, there is a fair chance
• Assuming in real life the number of vulnerabilities will be close to 0
Bromium Confidential
• Most of the above material was prepared in cooperation
with Rahul Kashyap ([email protected])
Bromium Confidential

similar documents