Threatpost, 6/27/18, with comments by Satya Gupta;
WebAssembly (Wasm) modules improve executive speed and can be used to compute-intensive tasks. Though it doesn’t replace JavaScript, Wasm is more efficient and often used with it. A future feature in Wasm’s roadmap – threading in shared memory – brings more efficiency and speeds things up even more by preventing redundancy in code.
Everyone likes their devices to perform faster but this improvement could come with an associated risk. Recent browser patches are already now in place to mitigate risks posed by the many variations of Spectre and Meltdown CPU vulnerabilities revealed in January. These browser patches are effective because they lower (reduce) the precision of JavaScript timers.
Backing up a bit, the Spectre and Meltdown threats are based on a CPU technique of executing an instruction before knowing for certain if that instruction is needed or allowed, or not. This so-called ‘speculative execution’ speeds up tasks and if the instruction isn’t allowed, it’s then discarded. The threat exists because during this process, the CPU is performing its tasks in fast memory – higher speeds than RAM – called CPU cache and CPU cache is at the heart of the Spectre and Meltdown exploits. Pulling off Spectre exploits requires hitting the CPU cache with very accurate timing. Accordingly, the means browsers have sought to reduce the threat is by lowering the precision of JavaScript timers to be less accurate.
However, the upcoming Wasm performance-increasing objectives would re-open the door for Spectre and Meltdown exploits by getting around these browser mitigations.
Aware of the problem, the WebAssembly group has put the threading feature on hold pending further examination.
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 full WebAssembly Changes Could Ruin Meltdown and Spectre Browser Patches article