May 21, 2021
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.
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.
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:
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.
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:
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
If you have any further questions, please contact Fastly Customer Engineering at support@fastly.com or the Fastly Security team at security@fastly.com