FYI: Code compiled to WebAssembly may lack standard security defenses

Mechanisms taken for granted on x86 vanish in WASM land, says trio


WebAssembly has been promoted for its security benefits, though researchers in Belgium and New Zealand contend applications built in this binary format lack important protections.

WebAssembly, or WASM, is a bytecode language produced by compiling source code written in languages like C/C++ and Rust. These output files are designed to run in both web and non-web environments and to do so in a sandboxed environment that's safely isolated from the host runtime. In effect, it allows developers to build and ship platform-independent applications that, say, your browsers can efficiently run.

WebAssembly's documentation describes the format's security goals, and boasts of its memory safety protection.

"[T]he presence of control-flow integrity and protected call stacks prevents direct code injection attacks," the WASM website explains. "Thus, common mitigations such as data execution prevention (DEP) and stack smashing protection (SSP) are not needed by WebAssembly programs."

Not so, say Quentin Stievenart and Coen De Roover, from Vrije Universiteit Brussel in Belgium, along with Mohammad Ghafari, from the University of Auckland in New Zealand.

In a paper titled, The Security Risk of Lacking Compiler Protection in WebAssembly, distributed via ArXiv, the technical trio say that when a C program is compiled to WASM, it may lack anti-exploit defenses that the programmer takes for granted on native architectures.

The reason for this, they explain, is that security protections available in compilers like Clang for x86 builds don't show up when WASM output is produced.

"We compiled 4,469 C programs with known buffer overflow vulnerabilities to x86 code and to WebAssembly, and observed the outcome of the execution of the generated code to differ for 1,088 programs," the paper states.

"Through manual inspection, we identified that the root cause for these is the lack of security measures such as stack canaries in the generated WebAssembly: while x86 code crashes upon a stack-based buffer overflow, the corresponding WebAssembly continues to be executed."

For those not in the know, a stack is a structure in memory used by programs to store temporary variables and information controlling the operation of the application. A stack canary is a special value stored in the stack. When someone attempts to exploit, say, a buffer overflow vulnerability in an application, and overwrite data on the stack to hijack the program's execution, they should end up overwriting the canary. Doing so will be detected by the program, allowing it to trap and end the exploitation attempt.

Without these canaries, an exploited WASM program could continue running, albeit at the bidding of whoever attacked it, whereas its x86 counterpart exits for its own protection, and that's a potential security problem. Stack canaries aren't a panacea, and they can be bypassed, though not having them at all makes exploitation a lot easier.

And these issues are not necessarily a deal-breaker: WASM bytecode still exists in a sandbox, and has further defenses against control-flow hijacking techniques such as return-oriented programming.

But as the researchers observe, WASM's documentation insists that stack-smashing protection isn't necessary for WASM code. The three boffins say their findings indicate security assumptions for x86 binaries should be questioned for WASM builds and should encourage others to explore the consequences of this divergent behavior, as it applies both to stack-based buffer overflows and other common security weaknesses.

"The divergences exposed here therefore mean that the WebAssembly binaries are exposed to stack-smashing attacks in the sense that, even though the program remains sandboxed in its environment, the control or data flow of the program may be exploited by an attacker," they conclude. ®

Broader topics


Other stories you might like

  • New audio server Pipewire coming to next version of Ubuntu
    What does that mean? Better latency and a replacement for PulseAudio

    The next release of Ubuntu, version 22.10 and codenamed Kinetic Kudu, will switch audio servers to the relatively new PipeWire.

    Don't panic. As J M Barrie said: "All of this has happened before, and it will all happen again." Fedora switched to PipeWire in version 34, over a year ago now. Users who aren't pro-level creators or editors of sound and music on Ubuntu may not notice the planned change.

    Currently, most editions of Ubuntu use the PulseAudio server, which it adopted in version 8.04 Hardy Heron, the company's second LTS release. (The Ubuntu Studio edition uses JACK instead.) Fedora 8 also switched to PulseAudio. Before PulseAudio became the standard, many distros used ESD, the Enlightened Sound Daemon, which came out of the Enlightenment project, best known for its desktop.

    Continue reading
  • VMware claims 'bare-metal' performance on virtualized GPUs
    Is... is that why Broadcom wants to buy it?

    The future of high-performance computing will be virtualized, VMware's Uday Kurkure has told The Register.

    Kurkure, the lead engineer for VMware's performance engineering team, has spent the past five years working on ways to virtualize machine-learning workloads running on accelerators. Earlier this month his team reported "near or better than bare-metal performance" for Bidirectional Encoder Representations from Transformers (BERT) and Mask R-CNN — two popular machine-learning workloads — running on virtualized GPUs (vGPU) connected using Nvidia's NVLink interconnect.

    NVLink enables compute and memory resources to be shared across up to four GPUs over a high-bandwidth mesh fabric operating at 6.25GB/s per lane compared to PCIe 4.0's 2.5GB/s. The interconnect enabled Kurkure's team to pool 160GB of GPU memory from the Dell PowerEdge system's four 40GB Nvidia A100 SXM GPUs.

    Continue reading
  • Nvidia promises annual updates across CPU, GPU, and DPU lines
    Arm one year, x86 the next, and always faster than a certain chip shop that still can't ship even one standalone GPU

    Computex Nvidia's push deeper into enterprise computing will see its practice of introducing a new GPU architecture every two years brought to its CPUs and data processing units (DPUs, aka SmartNICs).

    Speaking on the company's pre-recorded keynote released to coincide with the Computex exhibition in Taiwan this week, senior vice president for hardware engineering Brian Kelleher spoke of the company's "reputation for unmatched execution on silicon." That's language that needs to be considered in the context of Intel, an Nvidia rival, again delaying a planned entry to the discrete GPU market.

    "We will extend our execution excellence and give each of our chip architectures a two-year rhythm," Kelleher added.

    Continue reading
  • Amazon puts 'creepy' AI cameras in UK delivery vans
    Big Bezos is watching you

    Amazon is reportedly installing AI-powered cameras in delivery vans to keep tabs on its drivers in the UK.

    The technology was first deployed, with numerous errors that reportedly denied drivers' bonuses after malfunctions, in the US. Last year, the internet giant produced a corporate video detailing how the cameras monitor drivers' driving behavior for safety reasons. The same system is now apparently being rolled out to vehicles in the UK. 

    Multiple camera lenses are placed under the front mirror. One is directed at the person behind the wheel, one is facing the road, and two are located on either side to provide a wider view. The cameras are monitored by software built by Netradyne, a computer-vision startup focused on driver safety. This code uses machine-learning algorithms to figure out what's going on in and around the vehicle.

    Continue reading
  • AWS puts latest homebrew ‘Graviton 3’ Arm CPU in production
    Just one instance type for now, but cheaper than third-gen Xeons or EPYCs

    Amazon Web Services has made its latest homebrew CPU, the Graviton3, available to rent in its Elastic Compute Cloud (EC2) infrastructure-as-a-service offering.

    The cloud colossus launched Graviton3 at its late 2021 re:Invent conference, revealing that the 55-billion-transistor device includes 64 cores, runs at 2.6GHz clock speed, can address DDR5 RAM and 300GB/sec max memory bandwidth, and employs 256-bit Scalable Vector Extensions.

    The chips were offered as a tech preview to select customers. And on Monday, AWS made them available to all comers in a single instance type named C7g.

    Continue reading

Biting the hand that feeds IT © 1998–2022