Security advisories

Memory access due to code generation flaw in Cranelift module

Please see below for a Fastly Security Advisory (FSecA) outlining an investigation into CVE-2021-32629, a bug in 0.73.0 of the Cranelift x64 backend used to build WebAssembly modules, including those used by Fastly customers using Compute@Edge, disclosed by a recent Bytecode Alliance release[1].

It is our goal in this FSecA to explain that we clearly understand the applicability and impact of this investigation, and describe the remediation that has been implemented.

Applicability

This security advisory applies to customers who are using Compute@Edge, and whose modules were uploaded between 03/08/2021 and 04/22/2021. This does not apply to every customer, or modules that were not uploaded in that time frame.

Summary

The bug identified in the Cranelift x64 backend performs a sign-extend instead of a zero-extend on a value loaded from the stack, when the register allocator reloads a spilled integer value narrower than 64 bits. This interacts poorly with another optimization: the instruction selector elides a 32-to-64-bit zero-extend operator when we know that an instruction producing a 32-bit value actually zeros the upper 32 bits of its destination register. Hence, the x64 compiler relies on these zeroed bits, but the type of the value is still i32, and the spill/reload reconstitutes those bits as the sign extension of the i32’s MSB.

The issue would thus occur when:

  • An i32 value is greater than or equal to 0x8000_0000;
  • The value is spilled and reloaded by the register allocator due to high register pressure in the program between the value’s definition and its use;
  • The value is produced by an instruction that we know to be “special” in that it zeroes the upper 32 bits of its destination: add, sub, mul, and, or;
  • The value is then zero-extended to 64 bits;
  • The resulting 64-bit value is used.

Under these circumstances there is a potential sandbox escape when the i32 value is a pointer. The usual code emitted for heap accesses zero-extends the WebAssembly heap address, adds it to a 64-bit heap base, and accesses the resulting address. If the zero-extend becomes a sign-extend, the program could reach backward and access memory up to 2GiB before the start of its heap.

The result of this is that if a malicious module were executed, the result would typically be a crash due to an assertion from invalid LUCET_MAGIC, if the previous instance slot was not running, or the process would die due to an out-of-bounds trap. Fastly has found that a specially crafted WebAssembly module could target the vulnerable version of the Cranelift compiler in the Compute@Edge build process. If that happened, the WebAssembly module could access some memory in a different sandbox, or subvert control flow in the Compute@Edge daemon.

The vulnerability was discovered through routine monitoring of unusual behaviour by WebAssembly modules in Compute@Edge, and identified through analysis of a module uploaded by security researcher Javier Cabrera Arteaga of KTH Royal Institute of Technology. In the course of investigating the unusual behaviour Fastly engineers identified the bug and determined that it could be exploited, and worked with the Bytecode Alliance on a coordinated disclosure process.

Remediation

We have audited WebAssembly modules in Compute@Edge and confirmed that no WebAssembly modules in Compute@Edge were crafted in a manner to exploit this bug.

There is no Compute@Edge customer action required, and the issue has been fully remediated, with the following notes:

  • No customer requests were served by modules impacted by this issue
  • The vulnerability has been patched in the Compute@Edge Cranelift implementation
  • All customer WebAssembly modules have been recompiled using the updated compiler

Acknowledgements

This bug was identified by developers at Fastly following a report from Javier Cabrera Arteaga, KTH Royal Institute of Technology, with support from project Trustful of Stiftelsen för Strategisk Forskning. References [1] https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hpqh-2wqx-7qp5

Contact information

If you have any further questions, please contact Fastly Customer Engineering at support@fastly.com or the Fastly Security team at security@fastly.com

Subscribe to security advisories.

By submitting your request, you consent to your information being transmitted to Fastly in the United States for processing consistent with our Privacy Policy.

Ready to get started?

Get in touch or create an account.