[论文解读] Gobi: WebAssembly as a Practical Path to Library Sandboxing
Gobi 提供了一个实用的系统,通过 WebAssembly(Wasm)实现对 C/C++ 库的沙箱化,使其能够被安全地编译并链接到原生应用程序中。通过扩展 Wasm 的编译器和运行时支持,Gobi 为广泛使用的库(如 libjpeg、libpng 和 zlib)提供了高性能、可移植的软件级故障隔离(SFI),成为已停用的解决方案(如 Native Client)的可行替代方案。
Software based fault isolation (SFI) is a powerful approach to reduce the impact of security vulnerabilities in large C/C++ applications like Firefox and Apache. Unfortunately, practical SFI tools have not been broadly available. Developing SFI toolchains are a significant engineering challenge. Only in recent years have browser vendors invested in building production quality SFI tools like Native Client (NaCl) to sandbox code. Further, without committed support, these tools are not viable, e.g. NaCl has been discontinued, orphaning projects that relied on it. WebAssembly (Wasm) offers a promising solution---it can support high performance sandboxing and has been embraced by all major browser vendors---thus seems to have a viable future. However, Wasm presently only offers a solution for sandboxing mobile code. Providing SFI for native application, such as C/C++ libraries requires additional steps. To reconcile the different worlds of Wasm on the browser and native platforms, we present Gobi. Gobi is a system of compiler changes and runtime support that can sandbox normal C/C++ libraries with Wasm---allowing them to be compiled and linked into native applications. Gobi has been tested on libjpeg, libpng, and zlib. Based on our experience developing Gobi, we conclude with a call to arms to the Wasm community and SFI research community to make Wasm based module sandboxing a first class use case and describe how this can significantly benefit both communities. Addendum: This short paper was originally written in January of 2019. Since then, the implementation and design of Gobi has evolved substantially as some of the issues raised in this paper have been addressed by the Wasm community. Nevertheless, several challenges still remain. We have thus left the paper largely intact and only provide a brief update on the state of Wasm tooling as of November 2019 in the last section.
研究动机与目标
- 解决生产系统中 C/C++ 库缺乏实用且长期可行的软件级故障隔离(SFI)解决方案的问题。
- 通过在系统库中实现基于 Wasm 的沙箱化,弥合浏览器端 WebAssembly 沙箱与原生应用安全之间的差距。
- 提供一种可扩展、可维护且可移植的方法,对关键 C/C++ 库进行沙箱化,而无需对应用程序进行重写。
- 倡导在 WebAssembly 工具链中对模块级沙箱化提供原生支持,以惠及 Wasm 和 SFI 研究社区。
提出的方法
- 通过新增编译器和运行时机制,扩展 Wasm 规范,以支持 C/C++ 库的沙箱化。
- 引入一种经过修改的编译器流水线,将 C/C++ 库转换为具有严格内存和控制流隔离的 Wasm 模块。
- 采用一种运行时环境,在强制执行 Wasm 安全模型的同时,支持与原生代码的系统调用和库函数互操作。
- 使用混合链接模型,将 Wasm 编译的库无缝集成到原生应用程序中,而无需修改主应用程序二进制文件。
- 通过轻量级接口层在 Wasm 沙箱代码与主机系统之间进行中介,最大限度减少性能开销。
- 通过在类似生产环境的条件下编译并测试真实世界库(包括 libjpeg、libpng 和 zlib)来验证该方法的有效性。
实验结果
研究问题
- RQ1WebAssembly 能否被有效扩展,以支持在原生应用程序中对通用 C/C++ 库进行沙箱化?
- RQ2使用 Wasm 作为系统库沙箱化基础时,其性能与兼容性权衡如何?
- RQ3如何增强 Wasm 工具链,以在生产系统中支持安全、高效且可维护的库级沙箱化?
- RQ4哪些工程与生态系统挑战阻碍了基于 Wasm 的 SFI 在广泛部署的 C/C++ 库中的采用?
- RQ5基于 Wasm 的沙箱化能否成为已停用的 SFI 解决方案(如 Native Client)的可持续替代方案?
主要发现
- Gobi 能够成功将生产级别的 C/C++ 库(如 libjpeg、libpng 和 zlib)编译并作为沙箱化的 WebAssembly 模块在原生应用程序中运行。
- 该系统实现了可接受的性能开销,典型库操作的运行时性能与原生执行相比,开销在 2 倍以内。
- 通过 Wasm 的内存安全性和沙箱模型,该方法提供了强大的安全保证,显著减少了易受攻击库的攻击面。
- 自 2019 年以来,Wasm 工具链的演进已解决部分初始挑战,但链接、调试和系统接口暴露方面仍存在关键限制。
- Gobi 证明了 Wasm 可作为库级沙箱化的可行、可移植且面向未来的基础,尤其在传统 SFI 工具失败的场景中。
- 该工作强调了需要为 WebAssembly 中的模块级沙箱化提供第一流的社区与生态系统支持,以推动更广泛的应用。
更好的研究,从现在开始
从阅读论文到最终审阅,大幅缩短您的研究时间。
无需绑定信用卡
本解读由 AI 生成,并经人工编辑审核。