sandboxes: no thy limit
summary
Windows application sandboxes (examining Sandboxie, Adobe ReaderX and Chrome) have architectural limits: kernel bugs let sandboxed renderers escalate to SYSTEM via font parsing exploits and a user‑mode CSRSS flaw lets a low‑integrity process inject keystrokes and files into the host. Live demos include a kernel exploit that migrates to wininit and a CSRSS exploit that performs remote keystroke injection and uploads files. Chrome requires more chaining so type A sandboxes break far easier.
AI-written summary · about
chapters (26)
- 0:00Introduction
- 1:17Agenda
- 1:52What is a sandbox
- 2:42Types of sandbox
- 4:26OS internals
- 5:39Type A Sandbox
- 8:08Type B Sandbox
- 9:13Master vs Slave
- 10:54Object Integrity Levels
- 12:50Resistance to malicious slaves
- 14:06Adobe Reader
- 15:33Chrome
- 16:15Chrome Browser
- 16:48Pinkie Pie
- 17:56syscall filter
- 20:59how it works
- 22:19exploit
- 25:26serious problem
- 27:00user mode exploits
- 28:32LPC ports
- 29:08Adobe Reader vs Chrome
- 29:44PDF brute force
- 30:46CS RSS vulnerability
- 32:07CS RSS exploit
- 41:08Defense indepth
- 52:03Conclusion
related talks
41mThinking Outside the Sandbox - Violating Trust Boundaries in Uncommon Ways
45mThe Windows Sandbox Paradox
43mThe Most Secure Browser? Pwning Chrome from 2016 to 2019
40mDigging for IE11 Sandbox Escapes Part 2
57mDigging for IE11 Sandbox Escapes Part 1
01h 25mSandboxing a Linux Application
49mChrome Browser Exploitation: from zero to heap sandbox escape
50mLinux Security and How Web Browser Sandboxes Really Work
