SlideShare a Scribd company logo
Web-(Dis)Assembly
An in-depth peek inside the VM
running in your Web browser
Christophe Alladoum
Offensive Security Research - SophosLabs
Shakacon X - 07/18
Introduction
Preamble
3
• Who?
o Chris (@_hugsy_ on IRC / Twitter)
o Security researcher for SophosLabs
o CTF, low-level stuff addict, tool builder, software breaker
• Why?
o Asymmetry of “I’ve heard of WebAssembly” vs “I know what WebAssembly is”
o Huge new attack surface inside all browsers (mobile devices included)
o Is it worth checking out ?
o Can I detect / trace / debug it ?
o Can I cover everything in 45 minutes ?
Agenda
4
• Introduction
• Brief history of Web Assembly (WASM)
• WASM Minimum Viable Product (MVP), 1.0
• WASM attack surface
o Implementation in Web browsers
o Past bugs
• The future of WASM
• Conclusion & Q&A
Scope
5
• WebAssembly: what we’ll cover
o Specification
- File format
- Instruction set
o Focus on Web Browsers
- Interaction with DOM / JS Engine
- Attack surface / Fuzzing
- Past vulnerabilities leveraging WASM
• What we won’t cover (in details)
o Other use of WASM outside the Web world
NaCl ?
Asm.Js ?
WASM ?
6
Once upon a time…
7
• There is more to life than JavaScript !
• Wanting to execute fast custom code from Web apps
has been there for ages
o Most commonly used: ActiveX, Flash, Java
o Also emerged some terrible ideas: SilverLight, ShockWave
Once upon a time…
8
• There is more to life than JavaScript !
• Wanting to execute fast custom code from Web apps
has been there for ages
o Most commonly used: ActiveX, Flash, Java
o Also emerged some terrible ideas: SilverLight, ShockWave
• But
o Badly insecure
o Tough to secure/control at runtime by the browser
o Proprietary solutions
- Never standardized
Flash CVEs (source: cvedetails.com)
Java CVEs (source: cvedetails.com)
NaCl
9
• Google Native Client (2011)
o Designed to execute native code (x86/x64, ARM) in a sandbox
o Close to native performance
o 3D acceleration
o Debuggable using GDB-Remote
NaCl
10
• Google Native Client (2011)
o Designed to execute native code (x86/x64, ARM) in a sandbox
o Close to native performance
o 3D acceleration
o Debuggable using GDB-Remote
• But
o Not a standard
o Google Chrome {Browser,OS} specific
- Doesn’t apply to other browsers
Asm.Js
11
• Mozilla Asm.Js (2013) – “use strict;”
o Specification defining a strict subset of JavaScript
- Source to source code translation (from C)
- Ahead of time optimization
o EmScripten suite created to “compile” C/C++ code to Asm.JS code
o Can be up to 2x faster than traditional JavaScript
• Mission accomplished ?
o Wide adoption by Web developer community
o Not really…
- Still JavaScript
- Kind of a big hack
One language to rule them all…
12
• WebAssembly (March 2017)
o Best of both worlds: NaCl + Asm.Js
o W3C standard
o New stack-based virtual machine
- Not a sandbox
- Not JavaScript
o Uses its own ABI
- Limited instruction set
- Strict types
- Validate once, run forever
o Describes its own file format
- Simplified version of ELF
One language to rule them all…
13
• WebAssembly (March 2017)
o Close to native performance on simple operations
- Perfect for client-side computation
o (Officially) Designed with security in mind
o MVP fully functional, but easily extensible
• (Rather) Slow adoption
o Although huge potential
- 3D games can run smoothly in the browser
- Real-time application
https://webassembly.org/demo/
One language to rule them all…
14
Source: CanIUse.com
In a nutshell
15
Native Client (NaCl) Asm.Js WebAssembly
Close to native performance
Ahead-of-time compilation
W3C open standard
Security boundaries
In a nutshell
16
Native Client (NaCl) Asm.Js WebAssembly
Close to native performance
Ahead-of-time compilation
W3C open standard
Security boundaries
Web-Assembly: performance
17
• Many claim WASM is blazingly fast
Web-Assembly: performance
18
• Many claim WASM is blazingly fast
Web-Assembly: performance
19
• Many claim WASM is blazingly fast
Web-Assembly: performance
20
• Many claim WASM is blazingly fast
Native PE (no
optimization –O0)
Edge JS Edge WASM Chrome JS Chrome WASM Firefox JS Firefox WASM
0.90 13.1 0.97 9.15 1.23 7.54 0.92
Rapid benchmark (on i7 4th Gen, Windows 10): average* on 1 million SHA256
* In execution / μs
WebAssembly: side note
21
• Not just for the web
o Run WASM executable
- https://github.com/AndrewScheidecker/WAVM
o EOS (WASM for smart contracts)
- https://twitter.com/ryan_elfmaster/status/996527399138353152
o MicroKernel that runs WASM
- https://github.com/nebulet/nebulet
o WinDbg 10+
- Embeds ChakraCore from JS scripting support
- WASM is enabled ☺
- So yes, you can run WASM code from JS code inside Chakra
inside WinDbg!
WebAssembly: side note
22
• Enough with the marketing pitch, let’s dive into WebAssembly !
WebAssembly MVP 1.0
23
Web-Assembly Minimum Viable Product (MVP)
24
• First “stable” release – 1.0 (March 2017)
o "Viable" = provides a complete runtime environment
o Leaves room for further extension (“Post-MVP”)
• Strict specification of WASM format
o Small but (Turing-)complete instruction set (172 instructions)
- Arithmetic operation (including on float)
- Load/Store
- Control-Flow (branch, function call, return, etc.)
o Stack-based Virtual Machine
- No registers
- Little endian
- Strict types
- Flat 32-bit address space, page size to 64KB
- (Web) JIT-Translates WASM bytecode into native code
- Uses Variable-Length (Unsigned) Integers (varint/varuint) – VLQ
▪ 0x7F represented with 1 byte (x7F)
▪ 0x80 represented with 2 bytes (x81x00)
WebAssembly Instruction Set (brief) overview
25
Mnemonic Opcode Description
unreachable 0x00 Trap execution
nop 0x01 NOP instruction
if <block> /
else / end
0x04 / 0x05 / 0x06 Conditional branch
br / br_if /
br_table
0x0c / 0x0d / 0x0e BREAK from a block
call /
call_indirect
0x10 / 0x11 Function call
return 0x0f RETURN from function
Mnemonic Opcode Description
i32.load /
i64.load
0x28 / 0x29 Load integer from memory
f32.load /
f64.load
0x2a / 0x2b Load float from memory
i32.store /
i64.store
0x36 / 0x37 Store integer from memory
i32.store /
i64.store
0x36 / 0x37 Store float from memory
current_memory 0x3f Get the current memory size
grow_memory 0x40 Increase the memory size
Control Flow instructions
Memory access instructions
Mnemonic Opcode Description
i32.add / i32.sub /
i32.mul
0x6a / 0x6b / 0x6c Add / subtract / divide
i32.div_s / i32.div_u 0x6d / 0x6e (Un)signed Division
i32.rem_s / i32.rem_u 0x6f / 0x70 (Un)signed Modulo
i32.and / i32.xor /
i32.or / i32.shl
0x71 / 0x73 / 0x72 /
0x74
Logic operators
Arithmetic and logic instructions
WASM File Format – header
26
• File format designed for simplicity
o 8-byte static header
o (Optionally) N sections
o The shortest semantically valid WASM file is 8-byte long (header-only)
$ printf “x00x61x73x6dx01x00x00x00” > ./MyFirstWasmFile.wasm
8
WASM File Format – sections
27
• Each section has a header which states its purpose
• Section sequencing does not matter in the WASM file
o … But does when parsing it
WASM File Format – section header
28
Identifier Section name Description
0 Custom Custom section*
1 Type Function signature declarations
2 Import Import declarations
3 Function Function declarations
4 Table Indirect function table and other tables
5 Memory Memory attributes
6 Global Global declarations
7 Export Export
8 Start Start function declaration
9 Element Elements section
10 Code Function bodies (code)
11 Data Data segments
WASM File Format – Sections
29
• Function section
o Defines the signature of all the functions in the current WASM module
o Including:
- Number and type of arguments (0 or more)
- Number and type of return value (at most 1)
o Stored by index in table
• Code section
o Defines the body (code) of all the functions
o Indexes for entries in Code and Function section are linked
o Assembly function calls are specified by this index
10 00 call 0x00 Call the function of index 0
WASM File Format – Sections
30
• Export section - immutable
o Declares all objects to be exported
o Allows to expose functions, memory, data
- Can be consumed by another WASM module, by JavaScript (when running in browser), etc.
• Import section - immutable
o Declares all objects to be imported from another WASM module, from JS, or other
• Start section
o Holds the index to the start function to be called when execution starts (i.e. main()-like)
• Global section
o Defines all the global variables of the module
o Can specify whether a variable is mutable or not
Demo
31
WebAssembly:
from C to the Web
32
From C to WebAssembly: using tools
33
• Using toolkits like EmScripten
o Leverages LLVM IR to convert C code to WASM code
- Trivial to create WASM code using emcc compiler
o For Web apps, also generates a JavaScript loader + HTML (ugly) scaffold
int factorial(int n) {
if (n == 0)
return 1;
else
return n * factorial(n-1);
}
get_local 0
i64.const 0
i64.eq
if i64
i64.const 1
else
get_local 0
get_local 0
i64.const 1
i64.sub
call 0
i64.mul
end
20 00
42 00
51
04 7e
42 01
05
20 00
20 00
42 01
7d
10 00
7e
0b
C code WebAssembly text WebAssembly bytecode (in .wasm)
> GOOS=js GOARCH=wasm go build hello.go
> rustc --target=wasm32-unknown-emscripten hello.rs -o hello.html
> emcc –s WASM=1 factorial.c
From C to WebAssembly: using tools
34
• WASM Studio
o Web IDE that sets up an environment to write C or Rust
o Outputs .WASM + JS + HTML
https://webassembly.studio/
From C to WebAssembly
35
• WASM Explorer helps understands the transformation done
o Similar to Godbolt Compiler Explorer (but for WASM)
https://mbebenita.github.io/WasmExplorer/
Our custom toolkit
36
• Kaitai.io parser
• Kaitai-struct-based disassembler
• IDA Pro loader & processor
• All tools to be released on GitHub
after the talk
Into the Web Browser
37
• Compilers (like EmScripten) will generate a valid WASM file (with JS + HTML
loaders)
• .wasm is not a native MIME type for Web Browser, we need a loader
• Let’s use JavaScript!
o Fetch the WASM bytecode into a JS byte array (2 ways)
1 - If the WASM module is small enough (< 4096 bytes),
it can be inlined directly inside the JS code.
<html>
<body>
<script>
var WasmArrayBuffer = new Uint8Array(SIZE);
RawWasm[0] = 0x00; ‘0’
RawWasm[1] = 0x61; ‘a’
RawWasm[2] = 0x73; ‘s’
RawWasm[3] = 0x6d; ‘m’
[…]
Into the Web Browser
38
o (Cont.) Read the WASM bytecode from .wasm file (2 ways)
2 – Using EcmaScript 6 Promise feature (recommended approach)
o The JavaScript ArrayBuffer containing the WASM module is validated
syntaxically:
o The JS engine then parses the code, and JITs-it and issues native binary code.
<html>
<body>
<script>
document.addEventListener("DOMContentLoaded", StartWasm);
function StartWasm(event) {
fetch('hello-world.wasm').then(response =>
response.arrayBuffer()
);
[…]
var MyModule = new WebAssembly.Module(WasmArrayBuffer); // strict format, signature, types checks are done there
Into the Web Browser
39
o (Cont.) Declare a N-page large memory area and the JavaScript exports
o Finally, the VM can be instantiated
o The VM is running, can be interacted with via exported functions
function bar(){}
var memory = new WebAssembly.Memory({ initial : 20 }); // size=20*65536B
const exported = {
stdlib: { foo: bar }, // exposes “stdlib.foo” to WASM code
// but execute JS function bar
js: { memory: memory } // pass the reference to the memory area to VM
};
var MyInstance = new WebAssembly.Instance(MyModule, exported);
MyInstance.exports.ComputePi();
Demo
40
Web-(Dis)Assembly:
Attack Surface Analysis
41
WASM Security Consideration: the theory
42
• Entire section in the specification dedicated to security
- https://github.com/WebAssembly/design/blob/master/Security.md
o (1) Sandboxed code + Same-Origin-Policy (SOP) enforced
- Strict isolation
- enforcement of SOP (including CSP and HSTS)
o (2) Immutable code + Control-Flow Integrity (CFI) + Separated stack (for return address) +
static types
- Prevent buffer overflow exploitation
- Code cannot be written for execution after the module is parsed
- Cannot control code pointers, no traditional ROP/JOP
- No type confusion
WASM Security Consideration: the theory
43
• Entire section in the specification dedicated to security
- https://github.com/WebAssembly/design/blob/master/Security.md
o (1) Sandboxed code + Same-Origin-Policy (SOP) enforced
- Strict isolation, enforcement of SOP limits attack surface when loading WASM module
o (2) Immutable code + Control-Flow Integrity (CFI) + Separated stack (for return address) +
static types
- Prevent buffer overflow exploitation
- Code cannot be written for execution after the module is parsed
- Cannot control code pointers, no traditional ROP/JOP
- No type confusion
WASM Security Consideration: the reality
44
• Attack vectors against the protocol/specification
o Pretty hard…
- Function return hijacking: similar to traditional ROP, but by forcing return to existing indexes
- Race Conditions (TOCTOU): no atomicity of operation is guaranteed, memory can be shared
- Time-based Side-Channel attack (Spectre-like)
• Attack vectors against the implementations
o Easier (but not easy)…
- Most implementations are done in C/C++*
- Back to “traditional” vulnerabilities
▪ Memory corruption
▪ Race condition
WASM Security Consideration: the reality
45
WASM Security Consideration: the reality
46
WASM Security Consideration: the reality
47
WebAssembly: the interesting case of CVE-2017-5116
48
• Discovered and used by Qihoo 360 in Google Pixel exploit chain
o The Memory section passed to the WASM engine is backed by a
SharedArrayBuffer
o Attacker can create a worker that will try to change the index of a function during a
call instruction
o Race condition (TOCTOU): by winning, the attacker can redirect execution to a
controlled index, bypassing the WASM parser validation!
The instruction is checked as `call 0` (valid index)
But executed as `call 128` (out-of-bound index)
WebAssembly: the interesting case of CVE-2017-5116
49
• Very powerful vulnerability…
o Once validated, the code is never checked again.
• … But unlikely to be seen in the future
o SharedArrayBuffer objects are now removed / disabled on all recent versions
of Web browsers
- Thank you Spectre !
▪ Ironically, Spectre vulnerability would have been a perfect candidate for a WASM module:)
WASM & Web Browsers
50
• We’ve reviewed the implementations of the major Web browsers
• All JavaScript engine implementations are Open-Source!
o ChakraCore (Edge)
- ~ 48K LoC
o SpiderMonkey (Firefox)
- ~47K LoC
o V8 (Chrome)
- ~28K LoC
o JSC (WebKit)
- ~15K LoC
WASM & Web Browsers
51
• After ~2 weeks of fuzzing with different tools and strategies, JSC (WebKit)
showed a glimpse of hope
o Specifically crafted WASM file would make com.apple.WebKit.WebContent
crash
WASM & Web Browsers
52
• About ~30 unique crashes
WASM & Web Browsers
53
• About ~30 unique crashes
o But not exploitable … 
WASM & Web Browsers
54
• About ~30 unique crashes
o But not exploitable … 
WASM & Web Browsers
55
• In fact, most web browsers already provide their own tests/fuzzing scripts
o All because WASM has a strict binary format
- Perfect target for AFL/LibFuzzer fuzzing (unlike JS)
- Can be tested independently from JavaScript
• Security from Simplicity
o There is some other edge cases to test
o MVP 1.0 will soon be obsoleted by new release
- New features (new bugs?)
• Any other attack we could find?
o Arithmetic errors
o Denial-of-Service
o Race conditions in WASM memory byte array (shared with JS)
WASM & Web Browsers
56
• Example: Arithmetic error in WASM engine in Safari
We can access the value in the ArrayBuffer
We can’t access anymore, the value is forgotten
Abusing WebAssembly
57
• WebAssembly is a good candidate for Side-Channel attacks
o Although made harder by post-Spectre mitigations
• JavaScript code obfuscation (WAF/AV bypass etc.)
• Excellent use case for (not-so) bad guys: crypto-mining
o Used to be achieved by pure JavaScript code (like CoinHive)
o Computation resource -> close to native performance with WASM
o Already a few (Open-Source) variants spotted
- CryptoNight
- Xmonash
Crypto Mining is the process of bitcoin mining utilizing remote server(s) with shared
processing power.
eval( MyWasmInstance.exports.SomethingObfuscated() );
Abusing WebAssembly
58
• What about code inside the VM?
o Still affected by “traditional” C-style attacks
- Format strings
- Buffer overflow (stack, “heap”)
What about the defense ?
59
• Disable WASM ?
o Currently, only with a few tricks on Chrome & Firefox
- Not possible (yet) on Edge or Safari
- Firefox
▪ Set javascript.options.wasm to False in about:config
- Chrome
• Traffic inspection
o WebAssembly files have a distinct magic number (‘x00asm’)
o But hard to audit
$ chrome –js-flags=noexpose-wasm
What about the defense ?
60
• Static analysis
o IDA script to disassemble .wasm files
o wasm2c will generate a pseudo-C code (HexRays-decompiler style) from a WASM
file
• Complex projects (good or bad) will use a compiler (such as EmScripten)
o Can be used to flag binaries
- More complex when WASM embedded in JS
▪ But code size limited to 4096
o Generate AV signatures
- Risk of FP
- Hard to analyze dynamically
Future of WASM
(or why we should keep an eye open)
61
What’s next?
62
• Those features explained were specified in MVP 1.0
• WASM standard is still under very active development
o Overcome some limitations of the existing platform
o Provide additional features
o Improve integration with JS / DOM
What’s next?
63
What’s next?
64
• MVP allows many extensions including:
o On-demand memory allocation
▪ mmap()-like operation (munmap() too)
▪ Shared memory between multiple running modules
▪ Define permission mechanism (mprotect()-like)
- High memory pressure scenario ?
- Memory overlap ?
- Will this introduce pointers into WASM ?
o 64-bit integer support
- Integer overflow
o SIMD
▪ 128-bit floats
o Multi-threading
- Race conditions ?
• Some of those features are already being implemented in Firefox / Chrome
Conclusion
65
Conclusion
66
• WebAssembly is the new kid on the block, we should deal with it
o More applications will turn to it
- Active development
- More frameworks allow for a smooth transition from ASM.js and regular JS
o Security was not left out
- Robust specification, simple by design
▪ Limits the attack window
- But doesn’t prevent implementation bugs
o Keep an eye out for future specifications (and their implementations!)
Useful links
67
• Presentation + demo source code + custom toolkit
o https://github.com/Sophos/WebAssembly/
• Specification
o https://github.com/WebAssembly/design/blob/master/
• Toolkits
o https://mbebenita.github.io/WasmExplorer/
o https://webassembly.studio/
o https://wasdk.github.io/WasmFiddle/
o https://github.com/kripken/emscripten
o https://github.com/WebAssembly/wabt
• Bugs exploiting implementations
o https://android-developers.googleblog.com/2018/01/android-security-ecosystem-investments.html
o https://bugs.chromium.org/p/chromium/issues/detail?id=766253
o https://bugs.chromium.org/p/project-zero/issues/detail?id=1522
o https://bugs.chromium.org/p/project-zero/issues/detail?id=1545
o https://bugs.chromium.org/p/project-zero/issues/detail?id=1546
Thanks for listening !
--- EOT
68
Web (dis)assembly

More Related Content

Web (dis)assembly

  • 1. Web-(Dis)Assembly An in-depth peek inside the VM running in your Web browser Christophe Alladoum Offensive Security Research - SophosLabs Shakacon X - 07/18
  • 3. Preamble 3 • Who? o Chris (@_hugsy_ on IRC / Twitter) o Security researcher for SophosLabs o CTF, low-level stuff addict, tool builder, software breaker • Why? o Asymmetry of “I’ve heard of WebAssembly” vs “I know what WebAssembly is” o Huge new attack surface inside all browsers (mobile devices included) o Is it worth checking out ? o Can I detect / trace / debug it ? o Can I cover everything in 45 minutes ?
  • 4. Agenda 4 • Introduction • Brief history of Web Assembly (WASM) • WASM Minimum Viable Product (MVP), 1.0 • WASM attack surface o Implementation in Web browsers o Past bugs • The future of WASM • Conclusion & Q&A
  • 5. Scope 5 • WebAssembly: what we’ll cover o Specification - File format - Instruction set o Focus on Web Browsers - Interaction with DOM / JS Engine - Attack surface / Fuzzing - Past vulnerabilities leveraging WASM • What we won’t cover (in details) o Other use of WASM outside the Web world
  • 7. Once upon a time… 7 • There is more to life than JavaScript ! • Wanting to execute fast custom code from Web apps has been there for ages o Most commonly used: ActiveX, Flash, Java o Also emerged some terrible ideas: SilverLight, ShockWave
  • 8. Once upon a time… 8 • There is more to life than JavaScript ! • Wanting to execute fast custom code from Web apps has been there for ages o Most commonly used: ActiveX, Flash, Java o Also emerged some terrible ideas: SilverLight, ShockWave • But o Badly insecure o Tough to secure/control at runtime by the browser o Proprietary solutions - Never standardized Flash CVEs (source: cvedetails.com) Java CVEs (source: cvedetails.com)
  • 9. NaCl 9 • Google Native Client (2011) o Designed to execute native code (x86/x64, ARM) in a sandbox o Close to native performance o 3D acceleration o Debuggable using GDB-Remote
  • 10. NaCl 10 • Google Native Client (2011) o Designed to execute native code (x86/x64, ARM) in a sandbox o Close to native performance o 3D acceleration o Debuggable using GDB-Remote • But o Not a standard o Google Chrome {Browser,OS} specific - Doesn’t apply to other browsers
  • 11. Asm.Js 11 • Mozilla Asm.Js (2013) – “use strict;” o Specification defining a strict subset of JavaScript - Source to source code translation (from C) - Ahead of time optimization o EmScripten suite created to “compile” C/C++ code to Asm.JS code o Can be up to 2x faster than traditional JavaScript • Mission accomplished ? o Wide adoption by Web developer community o Not really… - Still JavaScript - Kind of a big hack
  • 12. One language to rule them all… 12 • WebAssembly (March 2017) o Best of both worlds: NaCl + Asm.Js o W3C standard o New stack-based virtual machine - Not a sandbox - Not JavaScript o Uses its own ABI - Limited instruction set - Strict types - Validate once, run forever o Describes its own file format - Simplified version of ELF
  • 13. One language to rule them all… 13 • WebAssembly (March 2017) o Close to native performance on simple operations - Perfect for client-side computation o (Officially) Designed with security in mind o MVP fully functional, but easily extensible • (Rather) Slow adoption o Although huge potential - 3D games can run smoothly in the browser - Real-time application https://webassembly.org/demo/
  • 14. One language to rule them all… 14 Source: CanIUse.com
  • 15. In a nutshell 15 Native Client (NaCl) Asm.Js WebAssembly Close to native performance Ahead-of-time compilation W3C open standard Security boundaries
  • 16. In a nutshell 16 Native Client (NaCl) Asm.Js WebAssembly Close to native performance Ahead-of-time compilation W3C open standard Security boundaries
  • 17. Web-Assembly: performance 17 • Many claim WASM is blazingly fast
  • 18. Web-Assembly: performance 18 • Many claim WASM is blazingly fast
  • 19. Web-Assembly: performance 19 • Many claim WASM is blazingly fast
  • 20. Web-Assembly: performance 20 • Many claim WASM is blazingly fast Native PE (no optimization –O0) Edge JS Edge WASM Chrome JS Chrome WASM Firefox JS Firefox WASM 0.90 13.1 0.97 9.15 1.23 7.54 0.92 Rapid benchmark (on i7 4th Gen, Windows 10): average* on 1 million SHA256 * In execution / μs
  • 21. WebAssembly: side note 21 • Not just for the web o Run WASM executable - https://github.com/AndrewScheidecker/WAVM o EOS (WASM for smart contracts) - https://twitter.com/ryan_elfmaster/status/996527399138353152 o MicroKernel that runs WASM - https://github.com/nebulet/nebulet o WinDbg 10+ - Embeds ChakraCore from JS scripting support - WASM is enabled ☺ - So yes, you can run WASM code from JS code inside Chakra inside WinDbg!
  • 22. WebAssembly: side note 22 • Enough with the marketing pitch, let’s dive into WebAssembly !
  • 24. Web-Assembly Minimum Viable Product (MVP) 24 • First “stable” release – 1.0 (March 2017) o "Viable" = provides a complete runtime environment o Leaves room for further extension (“Post-MVP”) • Strict specification of WASM format o Small but (Turing-)complete instruction set (172 instructions) - Arithmetic operation (including on float) - Load/Store - Control-Flow (branch, function call, return, etc.) o Stack-based Virtual Machine - No registers - Little endian - Strict types - Flat 32-bit address space, page size to 64KB - (Web) JIT-Translates WASM bytecode into native code - Uses Variable-Length (Unsigned) Integers (varint/varuint) – VLQ ▪ 0x7F represented with 1 byte (x7F) ▪ 0x80 represented with 2 bytes (x81x00)
  • 25. WebAssembly Instruction Set (brief) overview 25 Mnemonic Opcode Description unreachable 0x00 Trap execution nop 0x01 NOP instruction if <block> / else / end 0x04 / 0x05 / 0x06 Conditional branch br / br_if / br_table 0x0c / 0x0d / 0x0e BREAK from a block call / call_indirect 0x10 / 0x11 Function call return 0x0f RETURN from function Mnemonic Opcode Description i32.load / i64.load 0x28 / 0x29 Load integer from memory f32.load / f64.load 0x2a / 0x2b Load float from memory i32.store / i64.store 0x36 / 0x37 Store integer from memory i32.store / i64.store 0x36 / 0x37 Store float from memory current_memory 0x3f Get the current memory size grow_memory 0x40 Increase the memory size Control Flow instructions Memory access instructions Mnemonic Opcode Description i32.add / i32.sub / i32.mul 0x6a / 0x6b / 0x6c Add / subtract / divide i32.div_s / i32.div_u 0x6d / 0x6e (Un)signed Division i32.rem_s / i32.rem_u 0x6f / 0x70 (Un)signed Modulo i32.and / i32.xor / i32.or / i32.shl 0x71 / 0x73 / 0x72 / 0x74 Logic operators Arithmetic and logic instructions
  • 26. WASM File Format – header 26 • File format designed for simplicity o 8-byte static header o (Optionally) N sections o The shortest semantically valid WASM file is 8-byte long (header-only) $ printf “x00x61x73x6dx01x00x00x00” > ./MyFirstWasmFile.wasm 8
  • 27. WASM File Format – sections 27 • Each section has a header which states its purpose • Section sequencing does not matter in the WASM file o … But does when parsing it
  • 28. WASM File Format – section header 28 Identifier Section name Description 0 Custom Custom section* 1 Type Function signature declarations 2 Import Import declarations 3 Function Function declarations 4 Table Indirect function table and other tables 5 Memory Memory attributes 6 Global Global declarations 7 Export Export 8 Start Start function declaration 9 Element Elements section 10 Code Function bodies (code) 11 Data Data segments
  • 29. WASM File Format – Sections 29 • Function section o Defines the signature of all the functions in the current WASM module o Including: - Number and type of arguments (0 or more) - Number and type of return value (at most 1) o Stored by index in table • Code section o Defines the body (code) of all the functions o Indexes for entries in Code and Function section are linked o Assembly function calls are specified by this index 10 00 call 0x00 Call the function of index 0
  • 30. WASM File Format – Sections 30 • Export section - immutable o Declares all objects to be exported o Allows to expose functions, memory, data - Can be consumed by another WASM module, by JavaScript (when running in browser), etc. • Import section - immutable o Declares all objects to be imported from another WASM module, from JS, or other • Start section o Holds the index to the start function to be called when execution starts (i.e. main()-like) • Global section o Defines all the global variables of the module o Can specify whether a variable is mutable or not
  • 33. From C to WebAssembly: using tools 33 • Using toolkits like EmScripten o Leverages LLVM IR to convert C code to WASM code - Trivial to create WASM code using emcc compiler o For Web apps, also generates a JavaScript loader + HTML (ugly) scaffold int factorial(int n) { if (n == 0) return 1; else return n * factorial(n-1); } get_local 0 i64.const 0 i64.eq if i64 i64.const 1 else get_local 0 get_local 0 i64.const 1 i64.sub call 0 i64.mul end 20 00 42 00 51 04 7e 42 01 05 20 00 20 00 42 01 7d 10 00 7e 0b C code WebAssembly text WebAssembly bytecode (in .wasm) > GOOS=js GOARCH=wasm go build hello.go > rustc --target=wasm32-unknown-emscripten hello.rs -o hello.html > emcc –s WASM=1 factorial.c
  • 34. From C to WebAssembly: using tools 34 • WASM Studio o Web IDE that sets up an environment to write C or Rust o Outputs .WASM + JS + HTML https://webassembly.studio/
  • 35. From C to WebAssembly 35 • WASM Explorer helps understands the transformation done o Similar to Godbolt Compiler Explorer (but for WASM) https://mbebenita.github.io/WasmExplorer/
  • 36. Our custom toolkit 36 • Kaitai.io parser • Kaitai-struct-based disassembler • IDA Pro loader & processor • All tools to be released on GitHub after the talk
  • 37. Into the Web Browser 37 • Compilers (like EmScripten) will generate a valid WASM file (with JS + HTML loaders) • .wasm is not a native MIME type for Web Browser, we need a loader • Let’s use JavaScript! o Fetch the WASM bytecode into a JS byte array (2 ways) 1 - If the WASM module is small enough (< 4096 bytes), it can be inlined directly inside the JS code. <html> <body> <script> var WasmArrayBuffer = new Uint8Array(SIZE); RawWasm[0] = 0x00; ‘0’ RawWasm[1] = 0x61; ‘a’ RawWasm[2] = 0x73; ‘s’ RawWasm[3] = 0x6d; ‘m’ […]
  • 38. Into the Web Browser 38 o (Cont.) Read the WASM bytecode from .wasm file (2 ways) 2 – Using EcmaScript 6 Promise feature (recommended approach) o The JavaScript ArrayBuffer containing the WASM module is validated syntaxically: o The JS engine then parses the code, and JITs-it and issues native binary code. <html> <body> <script> document.addEventListener("DOMContentLoaded", StartWasm); function StartWasm(event) { fetch('hello-world.wasm').then(response => response.arrayBuffer() ); […] var MyModule = new WebAssembly.Module(WasmArrayBuffer); // strict format, signature, types checks are done there
  • 39. Into the Web Browser 39 o (Cont.) Declare a N-page large memory area and the JavaScript exports o Finally, the VM can be instantiated o The VM is running, can be interacted with via exported functions function bar(){} var memory = new WebAssembly.Memory({ initial : 20 }); // size=20*65536B const exported = { stdlib: { foo: bar }, // exposes “stdlib.foo” to WASM code // but execute JS function bar js: { memory: memory } // pass the reference to the memory area to VM }; var MyInstance = new WebAssembly.Instance(MyModule, exported); MyInstance.exports.ComputePi();
  • 42. WASM Security Consideration: the theory 42 • Entire section in the specification dedicated to security - https://github.com/WebAssembly/design/blob/master/Security.md o (1) Sandboxed code + Same-Origin-Policy (SOP) enforced - Strict isolation - enforcement of SOP (including CSP and HSTS) o (2) Immutable code + Control-Flow Integrity (CFI) + Separated stack (for return address) + static types - Prevent buffer overflow exploitation - Code cannot be written for execution after the module is parsed - Cannot control code pointers, no traditional ROP/JOP - No type confusion
  • 43. WASM Security Consideration: the theory 43 • Entire section in the specification dedicated to security - https://github.com/WebAssembly/design/blob/master/Security.md o (1) Sandboxed code + Same-Origin-Policy (SOP) enforced - Strict isolation, enforcement of SOP limits attack surface when loading WASM module o (2) Immutable code + Control-Flow Integrity (CFI) + Separated stack (for return address) + static types - Prevent buffer overflow exploitation - Code cannot be written for execution after the module is parsed - Cannot control code pointers, no traditional ROP/JOP - No type confusion
  • 44. WASM Security Consideration: the reality 44 • Attack vectors against the protocol/specification o Pretty hard… - Function return hijacking: similar to traditional ROP, but by forcing return to existing indexes - Race Conditions (TOCTOU): no atomicity of operation is guaranteed, memory can be shared - Time-based Side-Channel attack (Spectre-like) • Attack vectors against the implementations o Easier (but not easy)… - Most implementations are done in C/C++* - Back to “traditional” vulnerabilities ▪ Memory corruption ▪ Race condition
  • 48. WebAssembly: the interesting case of CVE-2017-5116 48 • Discovered and used by Qihoo 360 in Google Pixel exploit chain o The Memory section passed to the WASM engine is backed by a SharedArrayBuffer o Attacker can create a worker that will try to change the index of a function during a call instruction o Race condition (TOCTOU): by winning, the attacker can redirect execution to a controlled index, bypassing the WASM parser validation! The instruction is checked as `call 0` (valid index) But executed as `call 128` (out-of-bound index)
  • 49. WebAssembly: the interesting case of CVE-2017-5116 49 • Very powerful vulnerability… o Once validated, the code is never checked again. • … But unlikely to be seen in the future o SharedArrayBuffer objects are now removed / disabled on all recent versions of Web browsers - Thank you Spectre ! ▪ Ironically, Spectre vulnerability would have been a perfect candidate for a WASM module:)
  • 50. WASM & Web Browsers 50 • We’ve reviewed the implementations of the major Web browsers • All JavaScript engine implementations are Open-Source! o ChakraCore (Edge) - ~ 48K LoC o SpiderMonkey (Firefox) - ~47K LoC o V8 (Chrome) - ~28K LoC o JSC (WebKit) - ~15K LoC
  • 51. WASM & Web Browsers 51 • After ~2 weeks of fuzzing with different tools and strategies, JSC (WebKit) showed a glimpse of hope o Specifically crafted WASM file would make com.apple.WebKit.WebContent crash
  • 52. WASM & Web Browsers 52 • About ~30 unique crashes
  • 53. WASM & Web Browsers 53 • About ~30 unique crashes o But not exploitable … 
  • 54. WASM & Web Browsers 54 • About ~30 unique crashes o But not exploitable … 
  • 55. WASM & Web Browsers 55 • In fact, most web browsers already provide their own tests/fuzzing scripts o All because WASM has a strict binary format - Perfect target for AFL/LibFuzzer fuzzing (unlike JS) - Can be tested independently from JavaScript • Security from Simplicity o There is some other edge cases to test o MVP 1.0 will soon be obsoleted by new release - New features (new bugs?) • Any other attack we could find? o Arithmetic errors o Denial-of-Service o Race conditions in WASM memory byte array (shared with JS)
  • 56. WASM & Web Browsers 56 • Example: Arithmetic error in WASM engine in Safari We can access the value in the ArrayBuffer We can’t access anymore, the value is forgotten
  • 57. Abusing WebAssembly 57 • WebAssembly is a good candidate for Side-Channel attacks o Although made harder by post-Spectre mitigations • JavaScript code obfuscation (WAF/AV bypass etc.) • Excellent use case for (not-so) bad guys: crypto-mining o Used to be achieved by pure JavaScript code (like CoinHive) o Computation resource -> close to native performance with WASM o Already a few (Open-Source) variants spotted - CryptoNight - Xmonash Crypto Mining is the process of bitcoin mining utilizing remote server(s) with shared processing power. eval( MyWasmInstance.exports.SomethingObfuscated() );
  • 58. Abusing WebAssembly 58 • What about code inside the VM? o Still affected by “traditional” C-style attacks - Format strings - Buffer overflow (stack, “heap”)
  • 59. What about the defense ? 59 • Disable WASM ? o Currently, only with a few tricks on Chrome & Firefox - Not possible (yet) on Edge or Safari - Firefox ▪ Set javascript.options.wasm to False in about:config - Chrome • Traffic inspection o WebAssembly files have a distinct magic number (‘x00asm’) o But hard to audit $ chrome –js-flags=noexpose-wasm
  • 60. What about the defense ? 60 • Static analysis o IDA script to disassemble .wasm files o wasm2c will generate a pseudo-C code (HexRays-decompiler style) from a WASM file • Complex projects (good or bad) will use a compiler (such as EmScripten) o Can be used to flag binaries - More complex when WASM embedded in JS ▪ But code size limited to 4096 o Generate AV signatures - Risk of FP - Hard to analyze dynamically
  • 61. Future of WASM (or why we should keep an eye open) 61
  • 62. What’s next? 62 • Those features explained were specified in MVP 1.0 • WASM standard is still under very active development o Overcome some limitations of the existing platform o Provide additional features o Improve integration with JS / DOM
  • 64. What’s next? 64 • MVP allows many extensions including: o On-demand memory allocation ▪ mmap()-like operation (munmap() too) ▪ Shared memory between multiple running modules ▪ Define permission mechanism (mprotect()-like) - High memory pressure scenario ? - Memory overlap ? - Will this introduce pointers into WASM ? o 64-bit integer support - Integer overflow o SIMD ▪ 128-bit floats o Multi-threading - Race conditions ? • Some of those features are already being implemented in Firefox / Chrome
  • 66. Conclusion 66 • WebAssembly is the new kid on the block, we should deal with it o More applications will turn to it - Active development - More frameworks allow for a smooth transition from ASM.js and regular JS o Security was not left out - Robust specification, simple by design ▪ Limits the attack window - But doesn’t prevent implementation bugs o Keep an eye out for future specifications (and their implementations!)
  • 67. Useful links 67 • Presentation + demo source code + custom toolkit o https://github.com/Sophos/WebAssembly/ • Specification o https://github.com/WebAssembly/design/blob/master/ • Toolkits o https://mbebenita.github.io/WasmExplorer/ o https://webassembly.studio/ o https://wasdk.github.io/WasmFiddle/ o https://github.com/kripken/emscripten o https://github.com/WebAssembly/wabt • Bugs exploiting implementations o https://android-developers.googleblog.com/2018/01/android-security-ecosystem-investments.html o https://bugs.chromium.org/p/chromium/issues/detail?id=766253 o https://bugs.chromium.org/p/project-zero/issues/detail?id=1522 o https://bugs.chromium.org/p/project-zero/issues/detail?id=1545 o https://bugs.chromium.org/p/project-zero/issues/detail?id=1546
  • 68. Thanks for listening ! --- EOT 68