Security

How opaque WebAssembly code could increase the risk of Spectre attacks online

After the discovery of Spectre and Meltdown attacks, browser creators added new protections to defend against attacks. But WebAssembly code might undo all their hard work.

In the wake of the disclosure of Spectre and Meltdown vulnerabilities in January, browser vendors scrambled to create mitigations to prevent the vulnerabilities from being exploited via maliciously-crafted web pages, as a JavaScript-based proof-of-concept was developed by researchers that could read the memory of the host browser process. Foremost among the mitigations to this attack included disabling or reducing the precision of time counters in browsers.

For example, Mozilla reduced the precision of performance.now() to 20 microseconds as of Firefox 57, with that being reduced further to 2 milliseconds by default as of Firefox 59, though users can enable an additional setting in Privacy Settings to resist user fingerprinting, which reduces the precision to 100 milliseconds. This worked because Spectre and Meltdown, as side-channel attacks, require precise observation and manipulation of timers in order to be successfully exploited.

According to security firm Forcepoint, the new WebAssembly standard poses a threat to those mitigations. As the name implies, WebAssembly is an assembly-like format for executable code in web pages, allowing programs in high-level languages such as C/C++ to be compiled into WebAssembly-compliant bytecode, offering faster execution speed than JavaScript. The project is a successor to the vendor-specific asm.js and Native Client.

In a recent blog post, Forcepoint's John Bergbom cited the potential of a future version of WebAssembly gaining support for threads with shared memory as being able to bypass the restrictions in timer accuracy implemented earlier this year, though the WebAssembly developers are holding off on introducing the feature to avoid it being used for a high-precision timer as part of a Spectre attack.

SEE: System update policy (Tech Pro Research)

The problems presented by WebAssembly do not end there, in terms of security. Having a binary format script run automatically in browsers makes it particularly pernicious compared to JavaScript. As Bergbom noted in the post, while JavaScript can be obfuscated, it can still be deobfuscated with relative ease compared to WebAssembly.

Additionally, "there are not many publicly available tools for analyzing Wasm binaries," Bergbom said in the post. "Similarly, hardly any documentation exists on how to analyze a Wasm application at this time. This means that, largely, an unknown Wasm application can be a bit of a black box to a human analyst. The researcher may need to resort to analyzing only the network traffic, without being able to understand the inner workings of the code."

WebAssembly has also been seen as a vector for browser-based cryptojacking attacks, as the performance gains that WebAssembly offers greatly increase the return on investment of such attacks.

The big takeaways for tech leaders:
  • Because WebAssembly is a non-human-readable format, it presents a greater challenge for security researchers, and gives malicious actors more cover to deploy attacks.
  • Browser vendors reduced the accuracy of timers, and limited the ability to construct high-precision timers through other means, in an attempt to mitigate risk of Spectre attacks.

Also see

code.jpg
Image: iStockphoto/undrey

About James Sanders

James Sanders is a Tokyo-based programmer and technology journalist. Since 2013, he has been a regular contributor to TechRepublic and Tech Pro Research.

Editor's Picks

Free Newsletters, In your Inbox