智能合约安全之不一致性检查 - Al1ex

文章前言

本篇文章将通过对LightXXX合约内transfeFrom授权转账函数中的allowance不一致性检查问题和CountryXXX合约内transfeFrom授权转账函数中的balance不一致性问题对智能合约中的"不一致性检查"问题进行深入分析介绍，并以此来探究智能合约中值得关注的业务逻辑设计安全问题

漏洞原理

漏洞介绍：如下面代码所示，用于检查授权额度的条件语句require(_value <= allowed[from][msg.sender]);与后期业务逻辑中授权额度更新时的语句"allowed[_from][_to] -= _value;"存在不一致问题(即检查时检查的条件与后期更新时操作的对象并非同一个)，存在设计缺陷，该漏洞导致的危害是如果用户A给用户B授权转账后，用户B可以无限制的转走用户A的资产，直到转完账户的所有余额

漏洞介绍：如下面的代码所示，用于检查用户资产数量是否足够转账的条件检测语句"require(balances[msg.sender] >= _value);"与后期转账操作时更新用户资产数量的操作语句"balances[_from] -= _value;"存在不一致性，该漏洞操作的危害是攻击者能够通过溢出，让_from账户余额获得极大的token数量

漏洞复现

首先，下载LightXXX合约代码之后在本地Remix中进行部署调试(这里需要改一下合约中owner地址便于调试)，相关账户地址信息如下所示：

• 管理者：0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
• 攻击者1：0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2
• 攻击者2：0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db

Step 1：以管理者身份调用approve函数给予攻击者1一定的转账额度

approve:
"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2",10000

交易记录信息：

Step :2：使用allowance 查看转账额度：

"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2"

此时此时攻击者2的余额为0：

Step 3：之后切换为攻击者1身份，并通过攻击者1使用transferFrom向攻击者2进行转账操作

transferFrom： 
"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db",10000

交易记录信息如下：

Step 3：攻击者1继续使用:transferFrom向攻击者2进行转账操作，仍然能转账成功，因为 allowed[_from][msg.sender]没有发生变化

transferFrom： 
"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db",10000

交易日志记录：

之后发现攻击者2的余额依然增加了:

通过此攻击，攻击者能够将 _from 账户里的所有余额转移到其它用户余额中，并且allowed[_from][_to]是溢出了的~

allowance : 
"0x5B38Da6a701c568545dCfcB03FcB875f56beddC4","0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db"

首先，下载CountryXXX合约然后在Remix中进行部署分析调试(在构造函数中给msg.sender赋一些token)，相关地址如下：

• 管理者： 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
• 攻击者1：0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2
• 攻击者2：0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db

Step 1：在这里我们首先通过管理者地址给攻击者1地址打一定数量的代币进去，来模拟攻击者1充值token：

0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2,100000000000000

交易日志信息：

之后攻击者1的地址所拥有的token数量为：

另一个攻击者2地址账户余额为0

Step 2：接下来我们的攻击就是让第二个账户溢出，之后使用攻击者2给予攻击者1一定的转账额度权限

approve: 
"0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2",10000

Step 3：切换回攻击者1，然后使用transferFrom向自己进行转账操作

transferFrom： 
"0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db","0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2",10000

交易日志如下：

此时攻击者2地址上余额本来为0，但经过 “ 的减法计算下溢变为了一个极大值

修复方案

修复方法如下：
1、使用safeMath方法进行计算
2、使用balances[_from] >= _value作为条件判断而非 balances[msg.sender]
3、检查allowed[_from][msg.sender]并对allowed[_from][msg.sender]进行操作不要与allowed[_from][_to]混用
修复示例：

BY:先知论坛