Lin Clark, principal research engineer at Mozilla focusing on WebAssembly and Rust, discussed at the WebAssembly Summit the security challenges WebAssembly must address. Clark explained how the nano-process proposal strives to provide portable, secure-by-default WebAssembly modules.
Clark started by explaining why she chose to talk about security:
I realized that there was one thing that I really needed to talk about today and that’s a choice that’s facing us as a community at this moment. It’s a choice that we’re going to have to make as we build out this new ecosystem, and that choice is whether we want to use web assembly to build a safer future, or whether we want to take a worse is better approach, and extend the mistakes of the past. […] This choice is facing us now because web assembly is moving outside of the web.
The Worse is Better reference relates to a famous eponym essay written in the 1990s_by Richard P. Gabriel, in which he argued:
The lesson to be learned from this is that it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.
Gabriel, who since went on to write Worse is Better is Worse, oscillated in the following decade between the two opposite positions. This illustrates the difficulty of making growth decisions even, or maybe especially at an early stage of a technology. As WebAssembly is now a web standard, and strives to establish standards (such as WASI) also outside the web, how it decides to move forward is poised to have large implications on the software development ecosystem.
As WebAssembly is used to run outside the browser on servers, in the cloud, or IoT devices, it also leaves the browser sandbox behind. Clark argued that these environments are not architected to keep users safe in these circumstances and that bad actors are taking advantage of that at a dramatically increasing rate. Massively modular applications, in which 80% of the code base comes from external sources such as package managers npm, pypi, or crates.io, are particularly exposed to security attacks where malicious packages are abusing the trust granted by the main module. Those packages may thus enjoy unfettered access to the host file system, memory, system calls, and more.
Clark gave the example of the electron-native-notify's npm package through which a hacker stole 1.5 million dollars in crypto-currency and around 13 million dollars more on day zero. Before being used as an attack vector, that package had a useful feature: It helped Electron apps fire off native notifications in a way that worked across different platforms. Clark summarized the attack as follows:
- Day 0: attacker creates module.
- Day 2: attacker gets module into dependency
- Day 17: attacker adds malicious code
- Day 41-66: target runs npm update, pulling in malicious code.
At this point, the malicious code started sending off the seed, the username and password combination for the wallet to a server and the attacker could then use the seeds from all of these different wallets to empty those wallets
Day 90: attack detected
The attack used the access granted to system resources (memory holding the seed variable, network socket) and the host-provided APIs and system calls (opening sockets, sending data on sockets and more).
Clark warned that the number of malicious modules published to npm more than doubled from 2017 to 2019. Adam Baldwin, npm, Inc’s vice-president of security, pointed out that these attacks are getting more serious, more financially motivated, and patiently planned out.
Modular applications are also exposed to security risks stemming from package dependencies with known security vulnerabilities. Clark gave the example of the Zip Slip vulnerability, found in many ecosystems (JavaScript, Java, .Net, Go, Ruby, C++, Python, and more). Zip Slip is an arbitrary file overwrite critical vulnerability, which typically results in remote command execution. It affects thousands of projects, including ones from HP, Amazon, Apache, Pivotal, and many more (full list here). Snyk explained:
[Zip Slip] is especially prevalent in Java, where there is no central library offering high-level processing of archive (e.g. zip) files. The lack of such a library led to vulnerable code snippets being handcrafted and shared among developer communities such as StackOverflow .
Just like the previously mentioned attack, the Zip Slip attack would also use access to system resources (file system) and write system calls.
Snyk additionally reported that there has been an 88% increase in security vulnerabilities across software ecosystems over the past two years. A study of NPM packages found that 40% of packages depend on code with at least one publicly known vulnerability.
Clark thus suggested that a mechanism that restricts access to system resources, the host’s APIs and system calls, would go a long way to protect against malicious attackers and vulnerabilities. Clark described in the rest of the presentation solutions providing the desired restrictions. Regarding system resources, Clark described nano-processes, a new mechanism providing the same isolation than OS processes offer and a fine-grained form of per-module virtualization. Clark also described a capability-based security system in which modules can, at most, only give to dependent modules the access that they have been given themselves, and can decide to hand over only the relevant portion of the capabilities that they have.
Clark explained what is at stake with nano-processes:
It’s still just WebAssembly but it follows a particular pattern. If we build this pattern into the tools and conventions
that we use, we can make third-party code reuse safe in a way that it hasn’t been in any other ecosystem to date. […]
Following this pattern isn’t a requirement to use web assembly. If we want to have these security properties, we have to follow this pattern. We have to establish these conventions and bake them into our tools and that takes some work.
[…] it’s a problem that’s too big to solve alone. That’s why we worked with Fastly, Intel, Mozilla, and Red Hat and formed the Bytecode Alliance together. We’re creating tools built around the nano-process pattern [… and] we’re baking these [secure-by-default] conventions into the tools. […]
With this, developers can be as productive as they are today using open-source in the same way but without putting their users at risk.
Clark expressed the desire to see the rise of a new kind of ecosystem, one that doesn’t accept the trade-off between developer productivity and user safety, one that fixes what is broken and builds new secure-by-default foundations for native development that are portable and scalable.
The complete talk, including the full technical details, is available on the WebAssembly Summit Youtube channel.
The WebAssembly Summit was held in Silicon Valley, on the 10th of February, 2020. The WebAssembly Summit is a one-day, single-track conference about all things WebAssembly.