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!

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

By Pavol Luptak

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

The growing complexity of both hardware and software makes more difficult to detect security vulnerabilities or backdoors than ever before. Critical unexpected vulnerabilities have recently emerged in all-available processors (Meltdown / Specter). Browsers with lots of extensions are becoming the most complex Internet applications on your desktop or smartphone. The current architecture and used programming language make practically impossible to eliminate their hidden and unidentified vulnerabilities. Even the safest hardware wallets contain critical security vulnerabilities. Disk encryption, antivirus or anti-malware solutions running on compromised hardware or software are ineffective. In my presentation, I will try to explain how to survive in this wilderness and use compartmentalization to minimize the impact of unexpected black swans.

  • 3,233