TARDIS Placeholder
 

Is Web Assembly a Security Risk?

Cyber-criminals are increasingly using Web Assembly (WASM) to deploy malicious code, raising serious questions about the security model around Web Assembly and its future.

What are criminals using Web Assembly for?

The ability to run high-performance code on a compromised machine is particularly popular with cyber-criminals who want to run crypto-mining code on other people's computers, stealing computing resources, as reported by The Hacker News. The reported exploit may have been running for over a year without being detected.

Why is hard for anti-virus to detect Web Assembly issues?

Malicious web assembly code evades detection by anti-virus software as most normal anti-virus solutions are unable to check for problems in the low-level machine code of WASM files. The lack of integrity checking mechanisms in Web Assembly also makes it impossible to check if an application has been tampered with, raising the risk that even a WASM from a trusted provider could be compromised without the provider's knowledge.

Isn't Web Assembly safe because it runs in a "sandbox"?

One of the main ways in which Web Assembly code is supposedly made "safe" is by running it in a "sandbox" - an isolated area where it can only interact with a limited set of resources and can't, for example, make changes to files on your computer. Sandboxing is notoriously problematic; errors in the sandboxing code or in the code running in the sandbox can both cause breaches that break the supposed privacy and security of the sandbox. There are studies that illustrate weaknesses in Web Assembly that highlight scenarios where Web Assembly could write to arbitrary memory, overwrite sensitive data, or hijack control flow.

Furthermore, there is a danger that programmers believe that the sandboxed environment keeps them safe and fail to address errors in their code as a consequence. A study of C programs with known security issues showed that these errors were still present when the code was compiled to a Web Assembly. The conclusion from the researchers was ultimately that

Compiling an existing C program to WebAssembly for cross-platform distribution may require source code adaptations; otherwise, the security of the WebAssembly application may be at risk

One of the perceived strengths of Web Assembly is that it allows programmers to use any language that they want to write code for the web - if a WASM compiler exists for it, it can be made into a Web Assembly. The problem with this is that many of these developers may not be experienced in building for the web or understand the security challenges inherent in working with web applications and may bring with them dangerous coding practices and legacy bugs.

Yes, we've seen this before. Is WebAssembly going to have the same problems as Flash?

When Web Assembly first appeared on my radar, I wasn't convinced - moving heavyweight code from the server to the client felt like a design pattern that I'd seen before with the PC, smartphones, wearable technology, and so on and so forth. Invariably after we build a system that requires bigger and better processing on the client side to do more, we build technology to move the processing to the server side and allow for a thinner, lower-power client. We did it with the web, we're doing it with phones, we're doing it with gaming...

And, speaking of gaming, there's also a parallel for Web Assembly that I hadn't previously noticed - Adobe Flash. Once the darling of online game developers, Adobe Flash was another technology that promised high-performance computing running a safe "sandboxed" environment on the client side. After one too many security issues, Adobe Flash was blocked by major browsers and the platform was effectively killed off.

With more than a few security researchers highlighting WebAssembly security problems and recommending that you turn off Web Assembly in your browser, there is a real risk that WASM could go the same way. If it's not the browser makers that turn against WASM, it could be anti-virus providers - if they are unable to ensure browser security with WASM turned on, support from browser makers won't matter.

Should you build client side applications in Web Assembly?

My recommendation, right now, is a simple no. If you have an application that requires "heavy lifting", then do that work on the server side. You can even do it with a Web Assembly, if you are so inclined. Just keep that insecure, unverifiable code off you client's machines. And mine.


Site Powered By:  Kirby, Bootstrap 5, Masonry