1. Endpoint security via
Application sandboxing and virtualization:
Past, present, future
Rafal Wojtczuk rafal@bromium.com

2. Agenda
• We will talk mostly about securing Windows client systems
• Application sandboxes
• Sandboxie
• Chrome sandbox
• Virtualization-based sandboxes
• Qubes OS
• Bromium vSentry
Bromium Confidential

3. 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

4. Why we need sandboxing?
• Infeasible or too expensive to write a bug-free complex
code
• Many approaches (AV, HIPS, NIPS) have limited
effectiveness
•
Particularly against 0days
• Containing a malicious code in a jail is doable
• How effective?
Bromium Confidential

5. Types of application sandboxes
• Type A: OS enhancement based: Sandboxie, Buffer Zone
Pro etc.
• Type B: Master/slave model: Adobe ReaderX, Chrome
browser
Bromium Confidential

6. TYPE A
• Example: Sandboxie (available since 2006), BufferZone
Pro
• 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

7. Application Sandbox Type A
Bromium Confidential

8. 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
compromised
• The sandbox cannot
protect against malicious
kernel mode malware

9. TYPE B
• Example: Google Chrome (available since 2008), Adobe
•
•
•
•
•
Reader
Two processes - master and slave, talking over IPC
channel
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

10. Application Sandbox Type B
Bromium Confidential

11. 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)

12. 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

13. Is this a problem?
• Windows kernel issues are discovered increasingly
•
•
•
•
frequently
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

14. CVE-2011-3402
Exploit: MS11-087
SANDBOX BASED
DEFENSE “IN-DEPTH”
#EPICFAIL

15. 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
vector
• Even properly functioning
code can be abused

16. 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

17. 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

18. 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

19. 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

20. Qubes OS (available since 2010)
Bromium Confidential

21. 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
IOMMU/VT-d)
Centralized updates of all AppVMs based on the same
template
Disposable VMs
Bromium Confidential

22. 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

23. Bromium vSentry
Bromium Confidential

24. Bromium vSentry main features
• Available since 2012
• For Windows, based on type 2 hypervisor (derived from
Xen)
•
•
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

25. 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

26. Future
• 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

27. Acknowledgements
• Most of the above material was prepared in cooperation
with Rahul Kashyap (rahul@bromium.com)
Bromium Confidential