WebAssembly: A New World of Native Exploits on the Browser
1 like1,351 views
The document discusses WebAssembly (Wasm), highlighting its capabilities, potential exploit scenarios, and security challenges. It covers how native code can be compiled to Wasm, its performance benefits compared to JavaScript, and various attack vectors such as buffer overflows and function pointer overflows. The document also emphasizes the need for security measures and better practices for developers to mitigate risks associated with Wasm exploitation.
WebAssembly: A New World of Native Exploits on the Browser
- 1. WebAssembly A New World Of Native Exploits On The Web
- 2. Agenda • Introduction • The WebAssembly Platform • Emscripten • Possible Exploit Scenarios • Conclusion
- 3. Wasm: What is it good for? ● Archive.org web emulators ● Image/processing ● Video Games ● 3D Modeling ● Cryptography Libraries ● Desktop Application Ports
- 4. Wasm: Crazy Incoming ● Browsix, jslinux ● Runtime.js (Node), Nebulet ● Cervus ● eWASM
- 5. Java Applet Joke Slide ● Sandboxed ● Virtual Machine, runs its own instruction set ● Runs in your browser ● Write once, run anywhere ● In the future, will be embedded in other targets
- 6. What Is WebAssembly? ● A relatively small set of low-level instructions ○ Instructions are executed by browsers ● Native code can be compiled into WebAssembly ○ Allows web developers to take their native C/C++ code to the browser ■ Or Rust, or Go, or anything else that can compile to Wasm ○ Improved Performance Over JavaScript ● Already widely supported in the latest versions of all major browsers ○ Not limited to running in browsers, Wasm could be anywhere
- 7. Wasm: A Stack Machine
- 11. Wasm in the Browser ● Wasm doesn’t have access to memory, DOM, etc. ● Wasm functions can be exported to be callable from JS ● JS functions can be imported into Wasm ● Wasm’s linear memory is a JS resizable ArrayBuffer ● Memory can be shared across instances of Wasm ● Tables are accessible via JS, or can be shared to other instances of Wasm
- 12. Demo: Wasm in a nutshell
- 13. Emscripten ● Emscripten is an SDK that compiles C/C++ into .wasm binaries ● LLVM/Clang derivative ● Includes built-in C libraries, etc. ● Also produces JS and HTML code to allow easy integration into a site.
- 14. Old Exploits
- 15. Old Exploits: Integer Overflow ● Int overflows within the C code work as normal ○ Can be a gateway to other exploits or just a simple sign flip ● More interesting: JS numbers and C types and Wasm ○ Wasm: int32, int64, float32, float64 ○ JS: 253 -1 (or sometimes 232 -1) ○ C: more than I can fit on this slide
- 17. Old Exploits: Format String ● Right way: printf(“%s”,userstring) ● Wrong way: printf(userstring) ● Extra format specifiers appear to be pulling values from linear memory ● %n works fine, so we can write too! ● TODO
- 19. Old Exploits: Buffer Overflows ● Good ○ C doesn’t do bounds checking, so neither does Wasm ○ Overflows can overwrite interesting values ■ Change a privilege level, account balance, etc. ● Bad ○ If you overflow past your linear memory, you get a JS error ○ Function structure of Wasm means no call stack as we know it, no return pointers to overwrite, etc. ● Ugly
- 21. Old Exploits: Et Cetera ● Probably working vulns/exploits/techniques: ○ TOC/TOU ○ Timing/side channels ○ Race conditions ○ Heap-based arbitrary writes ● Probably doesn’t work ○ UAF, null dereferencing, etc. ○ Classic buffer overflows, ROP ○ Information Leaks
- 22. New Exploits
- 23. New Exploit: BOF -> XSS ● If a value exposed to Wasm is later reflected back to JS, and there’s a traditional buffer overflow, we should be able to overwrite the reflected value ○ We use a user-tainted value to overwrite a “safe” value ○ DOM-based XSS ○ Depends on what types of variables and how they were declared ● Likely to not be caught by any standard XSS scanners, since they won’t see the reflected value as editable ● BONUS: JS has control of the Wasm memory, tables, and instructions, so XSS also gives us control of any running Wasm if needed.
- 24. Emscripten: New Exploits Buffer Overflow -> XSS
- 25. New Exploit: FP Overflow ● Function pointers aren’t really “pointers” in the C sense ● Variables will store indexes to the function table ● Wasm code will say “grab the index from that variable, then call that function” ● We’ve already shown we can modify the values of some variables via overflows ● Can you see where this is going?
- 26. New Exploit: FP Overflow (2) ● Almost ROP? ○ Find functions you’d really like to call, but can’t, overflow the function pointers somewhere else to point to those functions ○ Bad news: Signatures much match ■ Silver lining: There are only 4 types in Wasm ● Look for useful functions within the context of the application ○ “transferMoney”, “changePW”, etc. ○ Or, just look for something that lets you run JS (maybe builtin!) ● Similar technique described by Jonathan Foote at Fastly (his is TC/Serialization-related)
- 27. Demo:FP Overwrite -> XSS
- 28. New Exploit: Server-side RCE ● All of the previous techniques can also be used against Node ● Remote Code Execution on the server
- 29. Demo:FP Overwrite -> RCE
- 30. Emscripten: Security Features ● Things that don’t matter: ○ Non-executable Memory (NX/DEP) ○ Stack Canaries ● Protections not present: ○ Address Space Layout Randomization (ASLR) ○ Library hardening (e.g. %n in format strings) ● Effective Mitigations: ○ Control Flow Integrity (CFI) ○ Function definitions and indexing (prevents ROP-style gadgets)
- 31. Application Developers ● Avoid emscripten_run_script and friends ● Run the optimizer ○ This removes automatically included functions that might have been useful for control flow attacks ● Use Control Flow Integrity ○ There is a performance penalty ● Fix your c bugs!
- 32. Attackers ● Look for emscripten_run_script and friends ● Use overflows or other write attacks to modify Wasm data ○ Possible XSS, can also modify the Wasm itself ○ Even if XSS is not possible, can still modify data or make arbitrary function calls in some cases ● Using these same tricks vs. Node -> RCE
- 33. More Information Whitepaper: Security Chasms of WASM - Tyler Lukasiewicz - Brian McFadden - Justin Engler Justin Engler [email protected] @justinengler Tyler Lukasiewicz [email protected] @_kablaa