论文简介

论文标题：ContractFuzzer: Fuzzing Smart Contracts for Vulnerability Detection

论文链接：ContractFuzzer: Fuzzing Smart Contracts for Vulnerability Detection

开源地址：gongbell/ContractFuzzer: The Ethereum Smart Contract Fuzzer for Security Vulnerability Detection (ASE 2018)

本篇论文提出了一个采用fuzzing技术对智能合约漏洞进行分类挖掘的工具，取名为ContractFuzzer。这篇论文是这该领域的开山之作。

可检测的漏洞分类与对应的检测方法

漏洞定义：

在调用send函数的时候gas默认为2300，这只足够调用空的fallback函数。若目标合约的fallback函数不为空（还有其他操作），则会导致gas不足进行回滚。若调用了send函数却没有检查返回值是否成功（默认成功），则可能发生意外的错误。

检测方法：

1. 调用了send()函数
2. send()函数在运行过程中抛出了ErrOutOfGas错误

漏洞定义：

若调用链中的每个调用都是对合约功能的直接调用，当发生异常时，所有交易都将被回滚（包括以太币转账）。 但是，对于至少一个通过低级调用方法（address.call()、address.delegatecall() 、address.send()）对地址进行调用的嵌套调用链，事务的回滚将 只停在调用函数处并返回false。

检测方法：

1. 若其嵌套调用中至少有一个抛出了异常，但根调用没有抛出异常。

漏洞定义：

当“转账函数”先进行转账，在清空账户余额的时候，重入漏洞就会发生。攻击者在fallback函数中再次调用“转账函数”，进行重复多次的取款。

检测方法：

1. 递归调用检测

2. 转账检测

漏洞定义：

如果智能合约采用区块产生的时间来进行一个随机数的构建，则可能遭到攻击。因为区块产生的时间值可以由矿工在一定的时间范围内自行定义。

检测方法：

1. 函数执行期间是否调用了TIMESTAMP操作码
2. 是否通过send()函数或call()函数发送以太

漏洞定义：

区块号依赖的弱点和时间戳依赖的原因相似，如果智能合约采用区块产生的编号来进行一个随机数的构建，则可能遭到攻击。因为区块产生的编号可以由矿工进行操控。

检测方法：

1. 函数执行期间是否调用了NUMBER操作码
2. 是否通过send()函数或call()函数发送以太

漏洞定义：

采用delegatecall调用目标函数，目标函数将会在发起调用的合约环境中执行，从而可能导致发起调用的合约参数被修改。

检测方法：

1. 函数执行期间是否调用了delegatecall()函数
2. 被delegatecall()所调用的函数是从原始的输入(msg.data)中获得的

漏洞定义：

当一个合约的转账功能完全依赖于调用外部合约的函数或外部Library时，一旦外部合约或Library自毁，则该合约的全部余额将无法取出。

检测方法：

1. 该合约能够接收以太
2. 本身没有transfer/send/call/suicide等功能，而是通过delegatecall()函数调用外部函数进行转账

ContractFuzzer流程图

0-在本地部署离线的私有链

1-分析合约的ABI接口和字节码，提取处参数类型以及函数签名

2-对合约池中的所有合约进行函数签名分析，并建立{合约，函数}的索引

3- 生成符合ABI规范的fuzzing输入以及变异输入

4-该工具将启动fuzzing过程，将生成输入数据输入的相应的ABI接口中

5-根据执行日志检测安全漏洞

智能合约静态分析

首先基于每个智能合约导出的JSON格式ABI，提取ABI中声明的所有函数签名、参数描述和数据类型。目的是建立{函数选择器，所有合约地址}的映射。

流程如下：

后记

这篇文章还有很多实验的过程以及细节没有整理进来，感兴趣的读者可以去翻翻论文看一下。总的来说这篇文章讲了一个大概的框架，没有提到具体的技术实现，不过ContractFuzzer是开源的（在本文的开头）。

接下来打算看一下fuzzing具体是一个什么样的过程，输入生成函数是怎么样的，插桩又是什么东东。倒是想看一下ContractFuzzer是怎么实现的，但是他是用go写的，要看的话我还得先go一下。

好，这次的论文就读到这里，下期见~