Wang Y, Zhou Z, Ren Z, et al. A Comprehensive Study of WebAssembly Runtime Bugs[C]//2023 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 2023: 355-366.

Introduction

考虑对漏洞进行分类

研究对象为4个Wasm

浏览器采用的Wasm
- V8：谷歌的开源JS和WAsm引擎，采用c++实现，被用在Chrome和Node.js中
- SpiderMonkey：Mozilla的JS和Wasm引擎，采用C++实现，被用在Firefox
独立的Wssm
- Wasmer：Rust实现，代码仓库 https://github.com/wasmerio/wasmer
- Wasmtime：Rust实现

回答6个问题

Wasm运行时漏洞的根本原因的分布：进行了漏洞分类并分析了分布
Wasm运行时漏洞的症状：帮助理解漏洞可能导致的结果，辅助如何设计oracle，分为6类
根本原因和症状之间的联系
Wasm运行时漏洞的修复时间
不同运行时漏洞的共同点

数据集和测试脚本已经开源

Wasm runtimes

wasm运行时负责将二进制wasm指令翻译为本地CPU的机器码，三种方法

解释执行解释器
提前编译为本地执行文件编译器
及时编译编译器浏览器一般用，因为用户体验较好

Methodology

收集漏洞：首先从closed和fixed中搜集所有已修复漏洞，得到BugSet1
收集漏洞修复的commit：漏洞提交到修复之前的commit（为了方便，筛掉了采用多个commit修复的情况），筛掉与代码无关的commit得到BugSet2（包含一个commit修复多个漏洞）和BugSet3
漏洞分类和标记：3位熟悉Wasm的人员对BugSet2中的漏洞手工进行标记，标记出root cause和symptom
根本原因：16类
症状：6类

Analysis

根本原因
- 不正确的算法实现是bug出现最多的地方 25.45%
- 内存问题占17.7%
症状
- 最常见的是crash，占比56.86%
- 不正确的功能占比22.15%
根本原因和症状之间的联系：
- 不正确的算法实现、内存、异常处理错误可能导致所有的症状（数量上53.52%）
- 79.01%的漏洞导致的结果是崩溃、不正确的功能，但是原因可能各异
修复漏洞花费的时间
- 修复时间快于GCC和LLVM
修复涉及到的代码和文件
- 超过50%的漏洞一个文件就修复了
- 外部API不兼容原因导致的修复文件最多，Bad performance症状涉及到的文件最多，平均4.45
- 修复代码行数的中位数从12-70变化
不同Wasm运行时之间的共同点：采用斯皮尔曼相关系数进行分析
- 取值范围在-1到1之间，-1表示完全负的单调关系，1表示完全正的单调关系，0表示没有单调关系,[0.8-1.0]表示相关性强
- 症状类似，原因相关性不强