WebAssembly changes could neutralize Meltdown and Spectre browser patches
Changes to the WebAssembly ( Wasm ) may neutralize the browser patches against Meltdown and Spectre. Wasm was created to improve execution speed for porting desktop applications to web-based en'ironments. 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 meant as a replacement for it. Wasm is often used in conjunction with JavaScript. Wasm modules may be used for performing computation intensive tasks and JavaScript and HTML for providing the UI and gluing things together.
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 patches for the Spectre and Meltdown family of CPU vulnerabilities uncovered in January, which have been partially fixed in browsers by lowering the precision of timers in JavaScript. With support for threads with shared memory, very accurate timers can be created. That may render browser patches of certain CPU side channel attacks ineffective.
A side-channel attack means that critical information can be inferred. Malicious programs that run with low privileges can use a Spectre / Meltdown exploit in order to read 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. One of those involves executing an instruction before knowing whether it's allowed or not. The reason behind this behavior is that if the instruction is allowed, then time is saved by checking permissions in parallel with the actual execution. 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, called CPU cache, which is at the heart of the Meltdown and Spectre flaws. If the instruction 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. 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. 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 patch.
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. 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. The WebAssembly group stated that they're putting the threading feature on hold until the issue can be fully examined. This latest issue shows that the fundamental chip flaws that have allowed Meltdown and Spectre cannot be fully patched at the browser level. WebAssembly programming tools can leverage the performance gains as well as security vulnerabilities of chip-level speculative execution, even if the browser has been patched to prevent it. Meltdown and Spectre can only be solved at the process memory level. The situation shows the difficulty in patching side-channel flaws effectively. The browser patches doesn't fix the underlying vulnerabilities, which could always be exploited through other means.