More Worries over the Security of Web Assembly

In 1887, Lord Acton famously wrote, “Power tends to corrupt, and absolute power corrupts absolutely.” He was, of course, referring to people who wield power, but the same could be said for software.

As Luke Wagner of Mozilla described in these pages in 2017, the Web has recently adopted a system that affords software running in browsers much more power than was formerly available—thanks to something called Web Assembly, or Wasm for short. Developers take programs written, say, in C++, originally designed to run natively on the user’s computer, and compile them into Wasm that can then be sent over the Web and run on a standard Web browser. This allows the browser-based version of the program to run nearly as fast as the native one—giving the Web a powerful boost. But as researchers continue to discover, with that additional power comes additional security issues.

One of the earliest concerns with Web Assembly was its use for running software that would mine cryptocurrency using people’s browsers. Salon, to note a prominent example, began in February of 2018 to allow users to browse its content without having to view advertisements so long as they allowed Salon to make use of their spare CPU cycles to mine the cryptocurrency Monero. This represented a whole new approach to web publishing economics, one that many might prefer to being inundated with ads.

Salon was straightforward about what it was doing, allowing readers to opt in to cryptomining or not. Its explanation of the deal it was offering could be faulted perhaps for being a little vague, but it did address such questions as “Why are my fans turning on?”

To accomplish this in-browser crypto-mining, Salon used a software developed by a now-defunct operation called CoinHive, which made good use of Web Assembly for the required number crunching. Such mining could also have been carried out in the Web’s traditional in-browser programming language, Javascript, but much less effectively.

Although there was debate within the computer-security community for a while about whether such cryptocurrency mining really constituted malware or just a new model for monetizing websites, in practice it amounted to malware, with most sites involved not informing their visitors that such mining was going on. In many cases, you couldn’t fault the website owners, who were oblivious that mining code had been sneaked onto their websites.

A 2019 study conducted by researchers at the Technical University of Braunschweig in Germany investigated the top 1 million websites and found Web Assembly to be used in about 1,600 of them. More than half of those instances were for mining crytocurrency. Another shady use of Web Assembly they found, though far less prevalent, was for code obfuscation: to hide malicious actions running in the browser that would be more apparent if done using Javascript.

To make matters even worse, security researchers have increasingly been finding vulnerabilities in Web Assembly, some that had been known and rectified for native programs years ago. The latest discoveries in this regard appear in a paper posted online by Daniel Lehmann and Michael Pradel of the University of Stuttgart, and Johannes Kinder of Bundeswehr University Munich, submitted to the 2020 Usenix Security Conference, which is to take place in August. These researchers show that Web Assembly, as least as it is now implemented, contains vulnerabilities that are much more subtle than just the possibility that it could be used for surreptitious cryptomining or for code obfuscation.

One class of vulnerabilities stems fundamentally from how Web Assembly manages memory compared with what goes on natively. Web Assembly code runs on a virtual machine, one the browser creates. That virtual machine includes a single contiguous block of memory without any holes. That’s different from what takes place when a program runs natively, where the virtual memory provided for a program has many gaps—referred to as unmapped pages. When code is run natively, a software exploit that tries to read or write to a portion of memory that it isn’t supposed to access could end up targeting an unmapped page, causing the malicious program to halt. Not so with Web Assembly.

Another memory-related vulnerability of Web Assembly arises from the fact that an attacker can deduce how a program’s memory will be laid out simply by examining the Wasm code. For a native application, the computer’s operating system offers what’s called address space layout randomization, which makes it harder for an attacker to target a particular spot in program memory.

To help illustrate the security weaknesses of Web Assembly, these authors describe a hypothetical Wasm application that converts images from one format to another. They imagine that somebody created such a service by compiling a program that uses a version of the libpgn library that contains a known buffer-overflow vulnerability. That wouldn’t likely be a problem for a program that runs natively because modern compilers include what are known as stack canaries—a protection mechanism that prevents exploitation of this kind of vulnerability. Web Assembly includes no such protections and thus would inherit a vulnerability that was truly problematic.

Although the creators of Web Assembly took pains to make it safe, it shouldn’t come as a great surprise that unwelcome applications of its power and unexpected vulnerabilities of its design have come to light. That’s been the story of networked computers from the outset, after all. [READ MORE]