Endpoint security via Application sandboxing and virtualization: Past, present, future

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

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

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

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?

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

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

7. Application Sandbox Type A

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

10. Application Sandbox Type B

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!

14. CVE-2011-3402 Exploit: MS11-087 SANDBOX BASED DEFENSE “IN-DEPTH” #EPICFAIL CVE-2012-1515 CVE-2012-0178 CVE-2012-2527 CVE-2012-1890 CVE-2011-2016 CVE-2011-2018 CVE-2011-3402 CVE-2012-1864 CVE-2012-1865 CVE-2012-1866 CVE-2012-1867 CVE-2012-1868 CVE-2012-0217 CVE-2012-0179 CVE-2012-0157 CVE-2012-0148 CVE-2012-0149 CVE-2011-5046 CVE-2012-0154 CVE-2012-0001 CVE-2013-1278 CVE-2013-1279 CVE-2013-1280 CVE-2013-0008 CVE-2012-2556 CVE-2012-4786 CVE-2012-2530 CVE-2012-2553 CVE-2012-2897 CVE-2013-1248 CVE-2013-1249 CVE-2013-1250 CVE-2013-1251 CVE-2013-1252 CVE-2013-1253 CVE-2013-1254 CVE-2013-1255 CVE-2013-1256 CVE-2013-1257 CVE-2013-1258 CVE-2013-1259 CVE-2013-1260 CVE-2013-1261 CVE-2013-1262 CVE-2013-1263 CVE-2013-1264 CVE-2013-1265 CVE-2013-1266 CVE-2013-1267 CVE-2013-1268 CVE-2013-1269 CVE-2013-1270 CVE-2013-1271 CVE-2013-1272 CVE-2013-1273 CVE-2013-1274 CVE-2013-1275 CVE-2013-1276 CVE-2013-1277

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.

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

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

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

20. Qubes OS (available since 2010)

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

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

23. BromiumvSentry

24. BromiumvSentry 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

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

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

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