Compartmentalization as an effective way to mitigate the negative impact of 0-day exploits


Pavol Luptak, Nethemba

The information asymmetry problem

  • The increasing information asymmetry between 0-day exploits owners (e.g. governments) and individuals 
  • Governments have
    • almost an unlimited budget for fully working 0-day exploits
    • special VIP rights (e.g. Information Secret Agencies)
    • non-transparent classified government "hacking" programs
  • Individuals have
    • almost no way to protect against 0-day exploits
    • no way to reveal any misuse of government hacking programs (thanks for Wikileaks!)


Recent 0-day exploits threatening iPhone users

  • Companies Cellebrite and Grayshift offer 0-day exploit iPhone cracking solution to the US police
  • The huge asymmetry between the police (which is able to crack the most of iPhones) and iPhone users (setting the complex password can save you)
  • The problem: just one 0-day exploit can fully compromise your privacy
  • Can we solve this issue?

0-day vulnerability as a unpredictable black swan

  • It is almost impossible to estimate the likelihood of 0-day vulnerability presence or include it in any risk management
  • It can be almost everywhere (CPU, hardware components, BIOS, kernel modules & drivers, libraries, applications)
  • The current hardware & software is just too complex to eliminate them
  • The most complex application in these days is probably the web browser (check the history of their successful hacks at Pwn2Own / CanSecWest)

Recent 0-day vulnerabilities in browsers

A collection of JavaScript engine CVEs with PoCs

  • Chrome
    • Building 1-day exploit
  • Firefox
  • Safari
    • Wasm Section Exploit

Cope with the fact:


Your daily used system/applications have 0-day vulnerabilities

How to survive in the world with omnipresent 0-day vulnerabilities?


  • Make their exploitation much harder:
    • A lot of anti-exploitation techniques (ASLR, DEP, anti-ROP, ..)
    • Sandboxing
    • Compartmentalization



  • Use a different VM for each application (and IOMMU for hardware memory segregation between VMs)
  • Use a different VLAN/network connection for each application
  • Use a different CPU for handling sensitive and non-sensitive operations (e.g. untrusted CPU vs TEE CPU)

Ease of compromise of normal laptop/desktop connected to the Internet

  • Requirement: ownership of 0-day browser/plugins exploit
  • Full compromise
    • Ownership of 0-day browser/plugins exploit + extra local root exploit

Ease of compromise of hardened laptop/desktop with compartmentalization

  • ​Requirement: ownership of 0-day browser/plugins exploit (and you will be still confined in the cage of the browser VM with your other applications being well protected)
  • Full compromise
    • Ownership of 0-day browser/plugins exploit + extra local root exploit for the given VM + extra IOMMU HW exploit + extra VM escalation exploit + extra local root exploit for the supervisor VM

Having & using of 4-5 different 0-day exploits AT ONCE is much less likely & much more expensive as having & using of one 0-day exploit (user compromise) or two 0-day exploits (full compromise)

(this may not be true if the system has a critical 0-day vulnerability in CPU and there is no compartmentalization on the CPU level)

Compartmentalization effectively and significantly decreases the likelihood of user/full compromise

Practical use-case:

Purism Librem + Qubes

Purism Librem

  • Hardware "kill-switch" (wifi/bluetooth/camera/microphone)
  • Most components are open hardware (from reputable vendors)
  • Intel ME "spying" functionality is neutralized
  • Opensource Coreboot instead of the proprietary BIOS
  • Opensource Heads implementation of TPM to protect rootkits/tampering

Qubes 4.0

  • Implements full compartmentalization based on XEN
  • Immune against Meltdown & Spectre attack
  • 3 kinds of virtualization: PV (paravirtualization),  PVH (paravirtualization with hardware support), HVM (full hardware virtualization)
  • Includes VMs based on Fedora 26, Debian 9, Whonix 13, but can be easily extended almost to any OS

PV vs PVH vs HVM

Qubes pre-installed network-based VMs


  • sys-whonix - Tor transparent gateway
  • sys-firewall - standard firewall (you can specify also OUTPUT policy)
  • sys-net - Internet access (otherwise it's blocked)
  • sys-usb - access to USB devices

My personal Qubes VMs

  • fedora-26-dvm – temporary disposable VM (browsing with no traces)
  • whonix-dvm (Tor access only) - temporary disposable VM (browsing with no traces using Tor)
  • TrustedCommunication  –  where my private Signal/SSH keys are stored
  • Trezor (with no network access) - where my password managers are stored
  • personal – where my personal apps (Spotify, Emacs, LibreOffice…) are stored
  • monero-wallet-ws (with no network access) – where my Monero private keys are stored
  • monerod-ws (Tor) – synchronized Monero blockchain over Tor


Qubes users includes Snowden, Peter Todd, DJ Bernstein and more

Practical use case:
Google Pixel 2 + Cooperhead OS

Google Pixel 2(XL)

  • Considered to be the most secure Android with special tamper-resistent hardware security module 
  • It uses Trusted Execution Environment (TEE).
  • The main processor on these devices is considered "untrusted" and cannot access certain areas of RAM, hardware registers and fuses where secret data (such as device-specific cryptographic keys) is stored by the manufacturer.
  • The TEE processor is isolated from the rest of the system using memory and I/O protection mechanisms supported by the hardware

  • Sandboxed user accounts

Google Pixel 2(XL)

Google states that even in the event of a full compromise elsewhere, the attacker cannot derive a user’s disk encryption key without compromising the security module first

Copperhead OS hardening

  • Chromium (64bits) supports per-site-instance sandboxing via isolatedProcess and seccomp-bpf
  • Bionic libc improvements - the default system allocator is replacted with a port of OpenBSD’s malloc implementation
  • Extended FORTIFY_SOURCE (buffer overflow checking), Function pointer protection
  • Enhanced SELinux policies & kernel hardening using linux-hardened

  • Custom hardened apps (PDF viewer, Silence)

  • SQLite’s SECURE_DELETE feature is enabled, resulting in deleted content being overwritten with zeros

  • And much more


  • It is not possible to build highly secure and complex OS/application at the same time
  • Always expect 0-day vulnerabilities and 0-day exploits in all systems and applications
  • Compartmentalization can be an effective way how to mitigate the negative impact of 0-day exploits
  • Try Purism Librem + Qubes (as a highly secure laptop) and Google Pixel 2 + Copperhead (as a highly secure smartphone)
  • Don't forget the most sensitive and critical part of security of all "privacy extremists" is always physical security

Thanks for your attention!