WebAssembly Changes Could Ruin Meltdown And Spectre Patches

Upcoming changes to the WebAssembly (Wasm) format may defang the browser patches for infamous side-channel attacks Meltdown and Spectre.

Wasm was invented to improve execution speed for porting desktop applications to web-based environments; programs are compiled in Wasm and then can easily be run in a browser. It’s more efficient than traditional JavaScript, but it’s not a replacement for it. Wasm is often used in conjunction with JavaScript.

“For example, Wasm modules may be used for performing computation intensive tasks and JavaScript (and HTML) for providing the UI and gluing things together,” explained Forcepoint researchers, in a posting Monday.

According to Wasm’s roadmap, one of the future features is threading in shared memory, which is an efficiency-booster that prevents redundancy in coding and speeds things up. This opens the door to get around browser mitigations for the Spectre and Meltdown family of CPU vulnerabilities uncovered in January, which have been partially mitigated in browsers by lowering the precision of timers in JavaScript.

“Once Wasm gets support for threads with shared memory, very accurate timers can be created,” said Forcepoint researchers. “That may render browser mitigations of certain CPU side channel attacks non-working.”

John Bergbom, senior security researcher at Forcepoint, explained the issue in more depth to Threatpost.

“A side-channel attack means that critical information can be inferred (as opposed to seen directly),” Bergbom said. “A malicious program that runs with low privileges can use a Spectre/Meltdown exploit in order to read (i.e. infer) very sensitive data that it is not supposed to have access to. A requirement for being able to infer the content of sensitive data is that the program has access to a very accurate timer.”

A modern CPU employs various techniques meant to speed up task execution – and one of those tricks involves executing an instruction before knowing for sure whether it’s allowed or not, Bergbom said.

“The reasoning behind this behavior is that if the instruction is allowed, then time is saved by checking permissions in parallel with the actual execution,” he said. “If it turns out that the instruction is not allowed, then the result of the executed instruction will be rolled back. This saves time if instructions turn out to be allowed most of the time.”

At the same time, a CPU has its own very fast memory inside (as opposed to normal RAM), dubbed a CPU cache, which is at the heart of the Meltdown and Spectre flaws:

“If the instruction at hand references memory that the process should not have access to, the data at that address might still have been loaded in the CPU cache (before rollback),” Bergbom said. “For performance reasons, the rollback does not remove the fetched data from the CPU cache. Since the data at the address referred by the rejected instruction is in the CPU cache, referencing the same address will execute faster than if we get a CPU cache miss. Measuring this timing difference makes it possible to infer contents of memory that the process should not have access to.”

Thus, having very accurate timers for measuring the difference between a CPU cache hit and cache miss is necessary to exploit the flaws. In response, browser vendors lowered the precision of timers as a mitigation.

When WebAssembly gets support for threads and shared memory, very accurate timers can be created to get around that.

“Thread A increments a counter and stored it at address X,” said Bergbom. “Thread B takes note of the counter stored at address X, does something, and then once again reads the value of the counter. Calculating the difference between the readings will effectively be an accurate timer.”

Taking note of the findings, the WebAssembly group said that they’re putting the threading feature on hold until the issue can be fully examined.

Satya Gupta, CTO and co-founder at Virsec, told Threatpost that the situation shows the difficulty in patching side-channel flaws effectively; the browser mitigations for instance don’t fix the underlying vulnerabilities, which could always be exploited through other means.

“This latest issue demonstrates that the fundamental chip flaws that have allowed Meltdown and Spectre cannot be fully patched externally – at the browser level,” he said. “In this case, WebAssembly programming tools can leverage the performance gains – and security vulnerabilities – of chip-level speculative execution, even if the browser has been patched to prevent it. Ultimately, Meltdown and Spectre can only be solved at the process memory level.”

READ MORE HERE