Browser Security: What’s Up with WASM?

WebAssembly, a newer type of “low-level” code that can be run by modern web browsers, is aimed at improving the web experience. The catch: Regular browsers execute such code locally. WebAssembly – merely a faster way for web-borne exploits to reach the local browser?

*

WebAssembly (WASM) is currently supported by major browsers including Firefox, Chrome, WebKit/Safari, and Microsoft Edge. Because the browser is running the WebAssembly code locally, any problems with that code also end up on the user’s machine and potentially pose a threat to the local IT environment.

How does WebAssembly work? WASM is not a high-level language. It is a way for language compilers (like those that read C, C++, and Rust high-level code) to express their assembly-level output in a different format. This output then can be directly executed by the browser.

Source: LogRocket Blog

By itself, WebAssembly code isn’t supposed to be able to do anything. It’s run inside a sandboxed virtual machine. WASM depends on other parts of its surrounding environment (Javascript or the browser itself) to actually handle tasks and passes information to these other helpers via an API.

There’s a logic behind this. Javascript (or the browser that can execute WASM code) already has the glue in place to deal with external tasks like writing to a screen. So why not take advantage of what’s already there?

Are WASM’s Security Safeguards Sufficient?

However, WebAssembly was specified to be run in a sandboxed execution environment for safety purposes. WebAssembly will additionally enforce the browser’s same-origin and permissions policies. There was some thought given by the language’s designers to basic security safeguards, especially in how memory is managed.

Yet in spite of the initial consideration, security problems have arisen with WASM. And not surprisingly, they are related to the inherent security weakness of the traditional browser model. WebAssembly code has been found, for example, to be a major component of cryptomining malware designed to hijack local browsers.

WASM has been a boon for cryptominers. The developers of Coinhive (one of the major miners) even stated that “Our miner uses WebAssembly and runs with about 65% of the performance of a native Miner.” They were drawn to WebAssembly for the performance boost it promised in the execution of the malware.

Good or Bad WASM? The Browser Wouldn’t Know.

One of the most obvious problems with WebAssembly is that there is not currently a means to do integrity checking on WASM code. This means there is no way to see if the actual code has been changed or altered in some way from a known “good” state before the browser executes it.

The lack of integrity checks would mean that the possibility exists that an attacker could substitute their own WASM code inside of a module that is going to be run by the browser without tripping any alarms. Since the actual code of the module is not directly human-readable, checking integrity would require some sort of pre-processor program to read the code before execution.

Once Again, Security Takes a Backseat

So why not add that component, you ask? The simple answer is that the added processing alone might negate any performance benefits in the code execution that WebAssembly promises.

There are more potential problems with WebAssembly. CVE-2018-5093 is one recent example that affects the Firefox browser. This heap buffer overflow vulnerability may occur in WebAssembly during Memory/Table resizing, resulting in a potentially exploitable crash.

Another recent vulnerability (CVE-2018-5094), which also affects the Firefox browser, is similar in nature. A heap buffer overflow vulnerability can occur in WebAssembly when "shrinkElements" is called followed by garbage collection on memory that is now uninitialized.

One more potential problem results from the use of multiple languages that are compiled into WASM code. If a developer cross-compiles an application into WebAssembly, any security problems the original application already has may be transferred as well.

Any exploits in libraries used by the original code will then also be present in the WASM code, where they may be hard to identify. In general, any problem present in the high-level language will also become a problem with WebAssembly.

Less Control = More Risk

Where WASM is executed in the local browser, all of these risk factors are entirely out of the user’s – and IT admin’s – control, leaving them (once again) at the mercy of programmers and their ability to avoid them. However, if the history of the web is any indication, this likely won’t be enough to keep WASM from becoming a raging success.

Because of the inherent security weaknesses of regular browsers, these problems with WASM were entirely predictable. As with Flash and Java in the 1990s, extending the functionality of the traditional browser model to run arbitrary code – in this case, WebAssembly – once again expands the local attack surface for web-borne exploits.

So should we just throw up our hands and go with the program?

Regain Control of the Browser

Fortunately, today you have a better way to take advantage of new code like WASM. You can do so without putting your local IT at risk. How about using a cloud browser, which processes all content securely in an isolated environment offsite?

A secure cloud browser completely insulates the local IT infrastructure from the consequences of bad WASM behavior. WASM-enhanced cryptominers won’t get a chance to gobble up local CPU resources.

The cloud browser model helps you regain control on the web. It ensures that web-borne bugs or exploits – whether introduced by WASM or any other internet code – are isolated and neutered in the cloud. This way, they can never reach the user’s machine and ripple from there through the local network.

Properly coded applications offering WASM must provide an asm.js fallback, which the cloud browser can execute. With a secure cloud browser, you (or your IT admin) don’t have to worry anymore about what could go wrong in the browser with WASM.

*

Larry Loeb has been online since uucp "bang" addressing (where the world existed relative to !decvax) and served as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange. He wrote for BYTE magazine, was a senior editor for the launch of WebWeek, and authored books on the Secure Electronic Transaction Internet protocol and "Hack Proofing XML" (his latest). Larry currently writes about cybersecurity for Security Now.