RSS Feed
更好更安全的互联网

以太坊安全之 EVM 与短地址攻击

2020-11-03

作者:昏鸦@知道创宇404区块链安全研究团队
时间:2020年8月18日

前言

以太坊(Ethereum)是一个开源的有智能合约功能的公共区块链平台,通过其专用加密货币以太币(ETH)提供去中心化的以太坊虚拟机(EVM)来处理点对点合约。EVM(Ethereum Virtual Machine),以太坊虚拟机的简称,是以太坊的核心之一。智能合约的创建和执行都由EVM来完成,简单来说,EVM是一个状态执行的机器,输入是solidity编译后的二进制指令和节点的状态数据,输出是节点状态的改变。

以太坊短地址攻击,最早由Golem团队于2017年4月提出,是由于底层EVM的设计缺陷导致的漏洞。ERC20代币标准定义的转账函数如下:

function transfer(address to, uint256 value) public returns (bool success)

如果传入的to是末端缺省的短地址,EVM会将后面字节补足地址,而最后的value值不足则用0填充,导致实际转出的代币数值倍增。

本文从以太坊源码的角度分析EVM底层是如何处理执行智能合约字节码的,并简要分析短地址攻击的原理。

EVM源码分析

evm.go

EVM的源码位于go-ethereum/core/vm/目录下,在evm.go中定义了EVM结构体,并实现了EVM.CallEVM.CallCodeEVM.DelegateCallEVM.StaticCall四种方法来调用智能合约,EVM.Call实现了基本的合约调用的功能,后面三种方法与EVM.Call略有区别,但最终都调用run函数来解析执行智能合约

EVM.Call
EVM.CallCode
EVM.DelegateCall
EVM.StaticCall

run函数前半段是判断是否是以太坊内置预编译的特殊合约,有单独的运行方式

后半段则是对于一般的合约调用解释器interpreter去执行调用

interpreter.go

解释器相关代码在interpreter.go中,interpreter是一个接口,目前仅有EVMInterpreter这一个具体实现

合约经由EVM.Call调用Interpreter.Run来到EVMInpreter.Run

EVMInterpreterRun方法代码较长,其中处理执行合约字节码的主循环如下:

大部分代码主要是检查准备运行环境,执行合约字节码的核心代码主要是以下3行

interpreter的主要工作实际上只是通过JumpTable查找指令,起到一个翻译解析的作用

最终的执行是通过调用operation对象的execute方法

jump_table.go

operation的定义位于jump_table.go

jump_table.go中还定义了JumpTable和多种不同的指令集

在基本指令集中有三个处理input的指令,分别是CALLDATALOADCALLDATASIZECALLDATACOPY

jump_table.go中的代码同样只是起到解析的功能,提供了指令的查找,定义了每个指令具体的执行函数

instructions.go

instructions.go中是所有指令的具体实现,上述三个函数的具体实现如下:

这三个函数的作用分别是从input加载参数入栈、获取input大小、复制input中的参数到内存

我们重点关注opCallDataLoad函数是如何处理input中的参数入栈的

opCallDataLoad函数调用getDataBig函数,传入contract.Inputstack.pop()big32,将结果转为big.Int入栈

getDataBig函数以stack.pop()栈顶元素作为起始索引,截取inputbig32大小的数据,然后传入common.RightPadBytes处理并返回

其中涉及到的另外两个函数math.BigMincommon.RightPadBytes如下:

分析到这里,基本上已经能很明显看到问题所在了

RightPadBytes函数会将传入的字节切片右填充至l位长度,而l是被传入的big32,即32位长度

所以在短地址攻击中,调用的transfer(address to, uint256 value)函数,如果to是低位缺省的地址,由于EVM在处理时是固定截取32位长度的,所以会将value数值高位补的0算进to的末端,而在截取value时由于位数不够32位,则右填充0x00至32位,最终导致转账的value指数级增大

测试与复现

编写一个简单的合约来测试

remix部署,调用transfer发起正常的转账

input0xa9059cbb00000000000000000000000071430fd8c82cc7b991a8455fc6ea5b37a06d393f0000000000000000000000000000000000000000000000000000000000000001

直接尝试短地址攻击,删去转账地址的后两位,会发现并不能通过,remix会直接报错

这是因为web3.js做了校验,web3.js是用户与以太坊节点交互的媒介

源码复现

通过源码函数复现如下:

实际复现

至于如何完成实际场景的攻击,可以参考文末的链接[1],利用web3.eth.sendSignedTransaction绕过限制

实际上,web3.js做的校验仅限于显式传入转账地址的函数,如web3.eth.sendTransaction这种,像web3.eth.sendSignedTransactionweb3.eth.sendRawTransaction这种传入的参数是序列化后的数据的就校验不了,是可以完成短地址攻击的,感兴趣的可以自己尝试,这里就不多写了

PS:文中分析的go-ethereum源码版本是commit-fdff182,源码与最新版有些出入,但最新版的也未修复这种缺陷(可能官方不认为这是缺陷?),分析思路依然可以沿用

思考

以太坊底层EVM并没有修复短地址攻击的这么一个缺陷,而是直接在web3.js里对地址做的校验,目前各种合约或多或少也做了校验,所以虽然EVM底层可以复现,但实际场景中问题应该不大,但如果是开放RPC的节点可能还是会存在这种风险

另外还有一个点,按底层EVM的这种机制,易受攻击的应该不仅仅是transfer(address to, uint256 value)这个点,只是因为这个函数是ERC20代币标准,而且参数的设计恰好能导致涉及金额的短地址攻击,并且特殊的地址易构造,所以这个函数常作为短地址攻击的典型。在其他的一些非代币合约,如竞猜、游戏类的合约中,一些非转账类的事务处理函数中,如果不对类似地址这种的参数做长度校验,可能也存在类似短地址攻击的风险,也或者并不局限于地址,可能还有其他的利用方式还没挖掘出来。

参考

[1] 以太坊短地址攻击详解

https://www.anquanke.com/post/id/159453

[2] 以太坊源码解析:evm

https://www.jianshu.com/p/f319c78e9714

Paper

本文由 Seebug Paper 发布,如需转载请注明来源。本文地址:https://paper.seebug.org/1296/

作者:江 | Categories:安全研究 | Tags:

发表评论