MSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code

Abstract

Most programs compiled to WebAssembly (Wasm) today are written in unsafe languages like C and C++. Unfortunately, memory-unsafe C code remains unsafe when compiled to Wasm—and attackers can exploit buffer overflows and use-after-frees in Wasm almost as easily as they can on native platforms. Memory- Safe WebAssembly (MSWasm) proposes to extend Wasm with language-level memory-safety abstractions to precisely address this problem. In this paper, we build on the original MSWasm position paper to realize this vision. We give a precise and formal semantics of MSWasm, and prove that well-typed MSWasm programs are, by construction, robustly memory safe. To this end, we develop a novel, language-independent memory-safety property based on colored memory locations and pointers. This property also lets us reason about the security guarantees of a formal C-to-MSWasm compiler—and prove that it always produces memory-safe programs (and preserves the semantics of safe programs). We use these formal results to then guide several implementations: Two compilers of MSWasm to native code, and a C-to-MSWasm compiler (that extends Clang). Our MSWasm compilers support different enforcement mechanisms, allowing developers to make security-performance trade-offs according to their needs. Our evaluation shows that on the PolyBenchC suite, the overhead of enforcing memory safety in software ranges from 22% (enforcing spatial safety alone) to 198% (enforcing full memory safety), and 51.7% when using hardware memory capabilities for spatial safety and pointer integrity. More importantly, MSWasm’s design makes it easy to swap between enforcement mechanisms; as fast (especially hardware-based) enforcement techniques become available, MSWasm will be able to take advantage of these advances almost for free.

Uma Estratégia Dinâmica para a Detecção de Anomalias em Binários WebAssembly

“…Por ser uma tecnologia recente, ainda existem vulnerabilidades de segurança e espaço para melhorias a serem explorados. Por exemplo, problemas como buffer overflow estão presentes em casos de interação entre JS e WebAssembly [Michael et al 2022]. Por conta da utilização de um buffer implementado por meio de um vetor para ser utilizado como memória do programa, problemas relacionados ao armazenamento de dados da aplicação também estão presentes [Lehmann et al 2020].…”

“…Desta forma, usuários maliciosos exploram o design do formato para realizar ataques cryptojacking e a ofuscação de códigos maliciosos [Naseem et al 2021]. A fim de mitigar tais riscos, estudos recentes focam em corrigir falhas de design, adicionar novos recursos e melhorar recursos já implantados, avaliando os problemas relacionados à memória [Michael et al 2022] e aperfeiçoando o design do compilador [Bosamiya et al 2022].…”