1. WebAssembly & Web-Browser CVEs

Long story short, WebAssembly (abbreviated Wasm) is a new portable, size- and load-time-efficient binary instruction format for the web. It has been designed by members of people representing the four browsers, Chrome, Edge, Firefox, and WebKit. WebAssembly is now supported/enabled by default by every major browsers (both on Desktop and Mobile) and WebAssembly module are executed through their respective javascript engines such as v8, spidermonkey, jsc, etc.

As you can see on caniuse.com, in January 2020, around 88% of all internet users can run WebAssembly modules on their browsers.

Adding supports of a new binary format designed to be loaded and executed by Javascript engines implied of course some huge modification on the source code i.e. from a researcher point of view, a new attack surface to discover 😉

If you want to discover more about existing WebAssembly browser CVEs, take a look at those links:

• The Problems and Promise of WebAssembly by natashenka – blogpost, slides
• A collection of JavaScript engine CVEs with PoCs – github
• Apple Safari Wasm Section Exploit CVE 2018-04-16 by MWR-labs – write-up

2. WebAssembly JavaScript APIs

Those APIs are our first targets for fuzzing since they are involved in multiple CVEs and they are common to every browser/JavaScript engine implementation. More details about those APIs and their syntaxes can be found here:

• WebAssembly by Mozilla MDN – link
• WebAssembly Web API by W3C – link
• Understanding the JS API – link

3. Create Dharma/Domato WebAssembly APIs grammars

In this blogpost, I will only target Chrome/V8 because it’s the best way for you (readers) to reproduce blogpost’s steps at home without spending hours in compilation/debugging. Just a quick reminder, AddressSanitizer (ASan) is a memory error detector based on compiler instrumentation (LLVM) and used to detect multiple kind vulnerabilities (UaF, HBoF, etc.).

Here is the main reasons why I choose fuzzing V8 engine/Chrome as a first choice:

• Google provide pre-built Chrome binaries built with AddressSanitizer i.e. no compilation for me today 😉
• One of the binary provided is d8, the V8’s own developer command line shell.
• You can specify to d8 (through cmd line option) if you want to activate under-development WebAssembly features (like anyref, threads, simd, etc.)
• Pre-built are fresh (up to date) and easy to download using Google gsutil tool and the following command.
• gsutil cp $(gsutil ls "gs://chromium-browser-asan/linux-release/asan-linux-release-*.zip" | tail -1) .

If you are looking to compile other JavaScript engines with ASan, check instructions in the links bellow:

• Building WebKit/JSC with ASan – link
• Firefox/Spidermonkey ASan builds + compilation intructions – link
• V8 build tests with ASan – link

Last but not least, we need to provide our JS files to d8. An easy way to start can be to create a simple bash script (like this one) that will loop and:

• execute d8 binary for each js file generated by Dharma
• monitor the returned signal value of the program
• store the testcase for analysis if the signal is not null.

This logic here is really basic and not optimal off course. If you don’t want to wrote some shell script, I can only suggest you to try the lazy way i.e. generate a lot of test-cases and let honggfuzz deal with them.

Honggfuzz is really easy-to-use and awesome fuzzer developed and maintained by Robert Swiecki from Google. During honggfuzz “dry-run”, all given files will be executed in different threads, monitored for crashes and stored if relevants. That also mean that only using the following command-line, you let honggfuzz handle everything and can go to sleep 😉

honggfuzz -t 5 -n 4 -i input_wasm_js/ -- ./d8 ___FILE___

Note: I noticed during my research that someone also integrate dharma directly into honggfuzz. I let you the check here, but personally I was not able to make it work :s

Any questions about our services and trainings ?

Get in touch today with any questions that you might have.