WebAssembly is an open standard low-level assembly language and binary format that executes at near-native speeds, compiled from languages like C/C++. It is designed to help web apps coded with JS in executing more efficiently. Wasm has capabilities not limited to the following:
Several tools can be used to compile C/C++ code into Wasm such as Emscripten, a compiler toolchain that runs in operating systems like Linux and Windows.
Converting the code using Emscripten would result in a Wasm bytecode as show in the image below. It should be noted that the first few hex bytes of the file indicating it as Wasm is 0x00 0x61 0x73 0x6D (“ asm”).
The image below is the loaded web page of the string “Hello, world!” initially written in C and converted to Wasm. Emscripten also automatically generates a basic HTML layout that correctly outputs the printf command of C upon loading in the browser. Even though Wasm is relatively new, web developers are keen to try out this tool for their applications. Various companies and entities are already adapting this new technology for the web.
All modern browsers support WebAssembly, although some browsers such as MS Edge Mobile and Extended Support Release of Firefox disable support for Wasm by default. Momentum is slowly gaining for industry acceptance and support as developers are implementing Wasm in their web applications.
Video games are known for being high-load applications that have heavy CPU and graphics memory usage. Early demonstrations of Wasm therefore focused on video games since Wasm is designed for efficiency and a minimal memory footprint. Two examples are the D3Wasm project and Unity. D3Wasm is a port of the id Tech 4 engine into Wasm, which can render the game “Doom 3”. Users are now able to play the game in any web browser that supports WebGL, showing that it is possible to load large programs with Wasm. In August 2018, the video game engine Unity switched their default target web format from asm.js to Wasm. They noted that Wasm is more efficient compared with asm.js in terms of smaller code size, memory efficiency during load time, and faster performance.
WebAssembly’s capabilities in image processing was recently demonstrated on Ebay’s online version of their bar code scanner. Users assumed that the old version of the application did not work properly because the processing time of the scanner was too slow. The new online scanner utilized both Wasm and JS and was found to be 50 times more efficient than the JS-only version of the application.
AutoCAD also created a version of their desktop software for the web that targets portability. Their initial development was built on the now-deprecated Adobe Flash, later switching to HTML5/JS. They were able to port their C++ code base into Wasm, some of which are 30 years old. The result is an application that can be accessed by the registered users over the web.
Lastly, Google Earth is the most recent and significant web application that uses Wasm. Like the above examples, the code base of Google Earth is in C++ and was ported using Emscripten. While the previous version of Google Earth was compiled in Native Client (NaCl) that only runs in Chrome, the newer version can be accessed by all major browsers that support Wasm. Currently the development of Wasm is a work in progress to adapt to newer Wasm-related technologies.
However, Wasm can still be used for malicious activities. An example would be a file collected by G DATA that was found to be compiled into Wasm. Based on the modules from its header the file was used for Cryptonight mining, an algorithm for cryptocurrency mining such as Monero and Electroneum.
Although Cryptonight is not malicious by itself, malware authors are compiling it into Wasm instead of JS and injecting them in websites to illicitly mine cryptocurrencies from users’ browsers by hijacking the CPU to use its processing power. This makes sense as JS is commonly used in crytpomining, the malware authors in this situation optimize their attack by leveraging Wasm to increase their mining efficiency as cryptomining requires large computing power.
According to research presented at Blackhat USA 2018, possible vulnerabilities that can use WebAssembly include cross-site scripting (XSS), where the function definitions in Emscripten calls JS to execute malicious code. If such vulnerabilities would exist in Wasm, then drive-by downloads that can be executed outside the browser environment are possible leading to malicious behavior like invoking PowerShell or process injection although no recent proof-of-concept are available yet to leverage these exploits in WebAssembly.
With its many possibilities, WebAssembly could be either a friend or a foe. It adds overwhelming advantages to applications development but can provide new avenues for vulnerabilities that may lead to exploits and malware attacks. However, adaption of Wasm for malicious activity is not yet imminent as development is still ongoing with continuous improvements in its security standards and general implementation in web browsers. The future of Wasm is anticipated, but we must prepare for any emerging threats that may surface.