By Marco Fioretti

Introduction

WebAssembly is, as we explained recently, a binary format for software written in any language, designed to eventually run on any platform without changes. The first application of WebAssembly is inside web browsers, to make websites faster and more interactive. Plans to push WebAssembly beyond the Web, from servers of all sorts to the Internet of Things (IoT), create as many opportunities as security issues. This post is an introductory overview of those issues and of the WebAssembly security model.

WebAssembly is like JavaScript

Inside web browsers, WebAssembly modules are managed by the same Virtual Machine (VM) that executes JavaScript code. Therefore, WebAssembly may be used to do much of the same harm that is doable with JavaScript, just more efficiently and less visibly. Since JavaScript is plain text that the browser will compile, and WebAssembly a ready-to-run binary format, the latter runs faster, and is also harder to scan (even by antivirus software) for malicious instructions.

This “code obfuscation” effect of WebAssembly has been already used, among other things, to pop up unwanted advertising or to open fake “tech support” windows that ask for sensitive data. Another trick is to automatically redirect browsers to “landing” pages that contain the really dangerous malware.

Finally, WebAssembly may be used, just like JavaScript, to “steal” processing power instead of data. In 2019, an analysis of 150 different Wasm modules found out that about 32% of them were used for cryptocurrency-mining.

WebAssembly sandbox, and interfaces

WebAssembly code runs closed into a sandbox managed by the VM, not by the operating system. This gives it no visibility of the host computer, or ways to interact directly with it. Access to system resources, be they files, hardware or internet connections, can only happen through the WebAssembly System Interface (WASI) provided by that VM.

The WASI is different from most other application programming interfaces, with unique security characteristics that are truly driving the adoption of WASM on servers/edge computing scenarios, and will be the topic of the next post. Here, it is enough to say that its security implications greatly vary, when moving from the web to other environments. Modern web browsers are terribly complex pieces of software, but lay on decades of experience, and of daily tests from billions of people. Compared to browsers, servers or IoT devices are almost uncharted lands. The VMs for those platforms will require extensions of WASI and thus, in turn, surely introduce new security challenges.

Memory and code management in WebAssembly

Compared to normal compiled programs, WebAssembly applications have very restricted access to memory, and to themselves too. WebAssembly code cannot directly access functions or variables that are not yet called, jump to arbitrary addresses or execute data in memory as bytecode instructions.

Inside browsers, a Wasm module only gets one, global array (“linear memory”) of contiguous bytes to play with. WebAssembly can directly read and write any location in that area, or request an increase in its size, but that’s all. This linear memory is also separated from the areas that contain its actual code, execution stack, and of course the virtual machine that runs WebAssembly. For browsers, all these data structures are ordinary JavaScript objects, insulated from all the others using standard procedures.

The result: good, but not perfect

All these restrictions make it quite hard for a WebAssembly module to misbehave, but not impossible.

The sandboxed memory that makes it almost impossible for WebAssembly to touch what is outside also makes it harder for the operating system to prevent bad things from happening inside. Traditional memory monitoring mechanisms like “stack canaries”, which notice if some code tries to mess with objects that it should not touch, cannot work there.

The fact that WebAssembly can only access its own linear memory, but directly, may also facilitate the work of attackers. With those constraints, and access to the source code of a module, it is much easier to guess which memory locations could be overwritten to make the most damage. It also seems possible to corrupt local variables, because they stay in an unsupervised stack in the linear memory.

A 2020 paper on the binary security of WebAssembly noted that WebAssembly code can still overwrite string literals in supposedly constant memory. The same paper describes other ways in which WebAssembly may be less secure than when compiled to a native binary, on three different platforms (browsers, server-side applications on Node.js, and applications for stand-alone WebAssembly VMs) and is recommended further reading on this topic.

In general, the idea that WebAssembly can only damage what’s inside its own sandbox can be misleading. WebAssembly modules do the heavy work for the JavaScript code that calls them, exchanging variables every time. If they write into any of those variables code that may cause crashes or data leaks in the unsafe JavaScript that called WebAssembly, those things will happen.

The road ahead

Two emerging features of WebAssembly that will surely impact its security (how and how much, it’s too early to tell) are concurrency, and internal garbage collection.

Concurrency is what allows several WebAssembly modules to run in the same VM simultaneously. Today this is possible only through JavaScript web workers, but better mechanisms are under development. Security-wise, they may bring in “a lot of code… that did not previously need to be”, that is more ways for things to go wrong.

A native Garbage Collector is needed to increase performance and security, but above all to use WebAssembly outside the well-tested Java VMs of browsers, that collect all the garbage inside themselves anyway. Even this new code, of course, may become another entry point for bugs and attacks.

On the positive side, general strategies to make WebAssembly even safer than it is today also exist. Quoting again from here, they include compiler improvements, separate linear memories for stack, heap and constant data, and avoiding to compile as WebAssembly modules code in “unsafe languages, such as C”.

The post WebAssembly Security, Now and in the Future appeared first on Linux Foundation – Training.

OSPOCon is an event dedicated to creating better, more efficient open source ecosystems.

SAN FRANCISCO, March 23, 2020 — The Linux Foundation, the nonprofit organization enabling mass innovation through open source, along with co-host the TODO Group, an open group of organizations who collaborate on practices, tools and other ways to run successful and effective open source programs and projects, has opened its Call for Proposals for OSPOCon.  The event will take place September 29 – October 1 in Dublin, Ireland, alongside Open Source Summit + Embedded Linux Conference 2021. The TODO Group has also launched an OSPO Landscape as a resource for the community to learn more about OSPOs. The community is encouraged to contribute to the landscape.

OSPOCon is a new event, dedicated to those working to create a center of competency for open source in their organizations in order to join together to overcome challenges through sharing experiences, best practices, and tooling. Open Source Program Offices (OSPOs) face many obstacles, such as ensuring high-quality and frequent releases, engaging with developer communities, and contributing back to other projects effectively. Collaborating together with others working on the same concerns helps the entire ecosystem improve.

“I am thrilled to be a part of the inaugural OSPOCon and see it brought to life to support the many hardworking and dedicated people involved in creating and sustaining OSPOs,” said Chris Aniszczyk, co-founder of the TODO Group and CTO at The Linux Foundation. “The impact OSPOs are having grows every day as they become a strategic function for organizations, from companies to governments to research institutions. Their contributions are tremendously valued and we look forward to furthering their abilities to collaborate, grow, and learn from each other.”

Proposals to speak at OSPOCon are being accepted now through June 13 at 11:59pm PDT.

Submission types requested include:

• Session Presentation (~40-50 minutes in length)
• Panel Discussion (~40-50 minutes in length)
• Birds of a Feather Session (BoFs are typically held in the evenings, (~45 minutes – 1 hour in length)
• Tutorial (~1.5 hours in length)
• Lightning Talk (~5-10 minutes in length)

Suggested Topics include:

Open Source Program Management

• Creation and Best Practices of Open Source Program Offices (OSPOs)
• Consuming and Contributing to Open Source
• Managing Competing Corporate Interests while Driving Coherent Communities
• How to Vet the Viability of OS Projects
• Internal vs External Developer Adoption
• Handling License Obligations in Organizations
• Open Source Corporate Sustainability

All interested parties are welcome to submit proposals. Those submitting will be notified of a decision by Thursday, July 22. To learn more and/or submit, please click here.

OSPOCon will be presented as a hybrid event – attendees can join and participate in person or virtually. Registration will open in late Spring 2021.  To receive an email alert when registration opens, please click here. The Linux Foundation provides diversity and need-based registration scholarships for this event to anyone that needs it; for information on eligibility please click here. Visit our website and follow us on Twitter, Facebook, and LinkedIn for all the latest event updates and announcements.

Sponsor:
OSPOCon offers two sponsorship levels for your consideration, Co-host and Supporter.  To see all sponsorship benefits, please click here or email us here.

Members of the press who would like to request a media pass should contact Kristin O’Connell.

About The Linux Foundation
The Linux Foundation is the organization of choice for the world’s top developers and companies to build ecosystems that accelerate open technology development and industry adoption. Together with the worldwide open source community, it is solving the hardest technology problems by creating the largest shared technology investment in history. Founded in 2000, The Linux Foundation today provides tools, training and events to scale any open source project, which together deliver an economic impact not achievable by any one company. More information can be found at www.linuxfoundation.org.

The Linux Foundation Events are where the world’s leading technologists meet, collaborate, learn and network in order to advance innovations that support the world’s largest shared technologies.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our trademark usage page: https://www.linuxfoundation.org/trademark-usage.

Linux is a registered trademark of Linus Torvalds.

####

Media Contact:
Kristin O’Connell
The Linux Foundation
koconnell@linuxfoundation.org

The post The Linux Foundation and the TODO Group Announce Call for Proposals for OSPOCon and the OSPO Landscape appeared first on Linux Foundation.