更详细的分析如下，
EOS Node Remote Code Execution Vulnerability — EOS WASM Contract Function Table Array Out of Bounds
英文的，这里复述下
代码在binaryen.cpp中：
libraries/chain/webassembly/binaryen.cpp
call_indirect_table_type table;
table.resize(module->table.initial);
for (auto& segment : module->table.segments) {
Address offset = ConstantExpressionRunner<TrivialGlobalManager>(globals).visit(segment.offset).value.geti32();
assert(offset + segment.data.size() <= module->table.initial);
for (size_t i = 0; i != segment.data.size(); ++i) {
table[offset + i] = segment.data[i];
}
}
这段代码再怎么看好像都没有问题，在assert中也已经作了边界检查：
assert(offset + segment.data.size() <= module->table.initial);
但是问题就出在assert上，assert是一个宏，而不是一个函数。在编译成Release版本时，它的定义如下：
#ifdef NDEBUG
#define assert(e) ((void)0)
#else
也就是编译成Release版本时，这个宏什么也没有干。
再来看下面的代码：
table[offset + i] = segment.data[i];
table定义为std::vector<Name>，当offset和module->table.initial都是从编译后的wasm代码里获取的，这样攻击者就可以生成一个恶意的wasm代码，使offset + segment.data.size() > module->table.initial，这样，就会导致table[offset + i]指向超出table内存的空间，而std::vector是不会作边界检查的，即使offset + i超出了索引，也不会抛异常的，导致非法的内存覆盖，这就是臭名昭著的OOB(out of bounds)漏洞。
有了OOB漏洞，接下攻击者要做的就是如何通过这个漏洞来远程执行代码了，文章中并没有给出细节。但是网上确实有很多公开的利用这种类型漏洞的来远程执行代码的工具和文章，这里不作深究，毕竟这不是写这篇文章的目的。解决这个漏洞也是非常的简单，将assert改成抛出异常即可，Eos已经修复了这个漏洞。
