区块链安全—经典溢出漏洞cve分析

一、前言

在上一篇文章中,我们详细地讲述了solidity中的整数溢出漏洞。而在本文中,我们将重点放在真实事件中,从0开始针对某些真实环境中的CVE进行复现操作。一步一步带领大家去了解合约内部的秘密。

本文中涉及的漏洞内容均为整数溢出的CVE,我们会对源代码进行详细的分析,并在分析漏洞的过程中讲述合约的搭建内容。

二、cve漏洞介绍

这次分析漏洞CVE-2018-11811。由于上次的文章我们详细的讲述了�整数溢出漏洞的原理以及一些合约实例。所以这次我们趁热打铁,针对真实�生产环境中的cve漏洞进行分析、复现。

这个漏洞是于今年6月12日由清华-360企业安全联合研究中心的张超教授团队披露出来的,安比(SECBIT)实验室针对这些漏洞,对以太坊上已部署的23357个合约进行了分析检测,发现共有866个合约存在相同问题。而今天我们讲述的这个漏洞共影响了288个智能合约。

合约源码如下:https://etherscan.io/address/0x0b76544f6c413a555f309bf76260d1e02377c02a

在详细讲述合约漏洞前,我们将合约的具体内容交代清楚。

这个合约发行了一套自己的token,并且可以用以太币对这些token进行交换。即包括:用户可以使用以太币兑换token,也可以出售token去获得以太币。而具体实现的函数如下:

这是owner对购买与卖出价格进行设定的函数:

function setPrices(uint256 newSellPrice, uint256 newBuyPrice) onlyOwner {
  sellPrice = newSellPrice;
  buyPrice = newBuyPrice;
}

下面是用户对token进行购买的函数:

function buy() payable {
  uint amount = msg.value / buyPrice;               // calculates the amount
  _transfer(this, msg.sender, amount);              // makes the transfers
}

这是用户出售token去换取以太币的函数:

function sell(uint256 amount) {
  require(this.balance >= amount * sellPrice);      // checks if the contract has enough ether to buy
  _transfer(msg.sender, this, amount);              // makes the transfers
  msg.sender.transfer(amount * sellPrice);          // sends ether to the seller. It's important to do this last to avoid recursion attacks
}

而问题就出在上面的三个函数中。最终达成的效果就是我平台的搭建者可以令用户用高价购买token却在卖出的时候以很便宜的价格卖出。从而达成对平台使用者的欺诈行为。

三、cve详细分析

1 合约详解

这个合约是多继承于其他合约而部署的。所以在分析的时候我们要有针对性。

首先,我们需要看主要的合约内容:

contract INTToken is owned, token {
  uint256 public sellPrice;
  uint256 public buyPrice;

  mapping (address => bool) public frozenAccount;

  /* This generates a public event on the blockchain that will notify clients */
  event FrozenFunds(address target, bool frozen);

  /* Initializes contract with initial supply tokens to the creator of the contract */
  function INTToken(
      uint256 initialSupply,
      string tokenName,
      uint8 decimalUnits,
      string tokenSymbol
  ) token (initialSupply, tokenName, decimalUnits, tokenSymbol) {}

  /* Internal transfer, only can be called by this contract */
  function _transfer(address _from, address _to, uint _value) internal {
      require (_to != 0x0);                               // Prevent transfer to 0x0 address. Use burn() instead
      require (balanceOf[_from] > _value);                // Check if the sender has enough
      require (balanceOf[_to] + _value > balanceOf[_to]); // Check for overflows
      require(!frozenAccount[_from]);                     // Check if sender is frozen
      require(!frozenAccount[_to]);                       // Check if recipient is frozen
      balanceOf[_from] -= _value;                         // Subtract from the sender
      balanceOf[_to] += _value;                           // Add the same to the recipient
      Transfer(_from, _to, _value);
  }

  /// @notice Create `mintedAmount` tokens and send it to `target`
  /// @param target Address to receive the tokens
  /// @param mintedAmount the amount of tokens it will receive
  function mintToken(address target, uint256 mintedAmount) onlyOwner {
      balanceOf[target] += mintedAmount;
      totalSupply += mintedAmount;
      Transfer(0, this, mintedAmount);
      Transfer(this, target, mintedAmount);
  }

  /// @notice `freeze? Prevent | Allow` `target` from sending & receiving tokens
  /// @param target Address to be frozen
  /// @param freeze either to freeze it or not
  function freezeAccount(address target, bool freeze) onlyOwner {
      frozenAccount[target] = freeze;
      FrozenFunds(target, freeze);
  }

  /// @notice Allow users to buy tokens for `newBuyPrice` eth and sell tokens for `newSellPrice` eth
  /// @param newSellPrice Price the users can sell to the contract
  /// @param newBuyPrice Price users can buy from the contract
  function setPrices(uint256 newSellPrice, uint256 newBuyPrice) onlyOwner {
      sellPrice = newSellPrice;
      buyPrice = newBuyPrice;
  }

  /// @notice Buy tokens from contract by sending ether
  function buy() payable {
      uint amount = msg.value / buyPrice;               // calculates the amount
      _transfer(this, msg.sender, amount);              // makes the transfers
  }

  /// @notice Sell `amount` tokens to contract
  /// @param amount amount of tokens to be sold
  function sell(uint256 amount) {
      require(this.balance >= amount * sellPrice);      // checks if the contract has enough ether to buy
      _transfer(msg.sender, this, amount);              // makes the transfers
      msg.sender.transfer(amount * sellPrice);          // sends ether to the seller. It's important to do this last to avoid recursion attacks
  }
}

这是最终的合约。这也是安全隐患发生的地方。

下面我们详细的分析一下这个合约的功能。

首先,这个合约继承了owned, token合约。而我们向上看,owned合约为:

contract owned { 
  address public owner;
  function owned() {
      owner = msg.sender;
  }
  //构造函数,初始化合约owner

  modifier onlyOwner {
      require(msg.sender == owner);
      _;
  }

  function transferOwnership(address newOwner) onlyOwner {
      owner = newOwner;
  }

}

这个合约比较简单,构造函数将合约的owner变量初始化,并且定义了限定函数--onlyOwner。这个函数限定了调用者必须是合约拥有者。之后为了后面开发方便,合约又定义了transferOwnership,用这个函数来改变现在的合约owner。

这也为我们的开发提醒,因为solidity合约部署之后是无法改变的,所以我们要尽可能的为后来的修改做考虑,增加一些必要的函数。

下面我们看第二个父合约:token

我们的主合约在启动时调用构造函数:

 function INTToken(
      uint256 initialSupply,
      string tokenName,
      uint8 decimalUnits,
      string tokenSymbol
  ) token (initialSupply, tokenName, decimalUnits, tokenSymbol) {}

而构造函数只有简单的传参操作,所以很明显它是调用了父合约token的构造函数:

function token(
      uint256 initialSupply,
      string tokenName,
      uint8 decimalUnits,
      string tokenSymbol
      ) //传入参数

  {
      balanceOf[msg.sender] = initialSupply;              // Give the creator all initial tokens 初始化用户金额
      totalSupply = initialSupply;                        // Update total supply 更新总金额
      name = tokenName;                                   // Set the name for display purposes  
      symbol = tokenSymbol;                               // Set the symbol for display purposes 显示小数的符号
      decimals = decimalUnits;                            // Amount of decimals for display purposes 更新小数的值
  }

其中传入了四个参数,分别代表庄家初始化总金额、token的名字、小数部分的具体值、token的标志类型

之后是主合约的_transfer函数,这个函数从新定义了其父合约的同名函数。在父合约中,其函数定义为:

  function _transfer(address _from, address _to, uint _value) internal {
      require (_to != 0x0);                               // Prevent transfer to 0x0 address. Use burn() instead
      require (balanceOf[_from] > _value);                // Check if the sender has enough
      require (balanceOf[_to] + _value > balanceOf[_to]); // Check for overflows  检查溢出
      balanceOf[_from] -= _value;                         // Subtract from the sender 
      balanceOf[_to] += _value;                            // Add the same to the recipient
      Transfer(_from, _to, _value);
  }

传入转账方已经接收方的地址以及转账的值。之后调用了一些判断,包括:“接收方地址不为0、转账方的余额>转账金额;增加了防止溢出的判断”。

而子合约中,在上述基础上又增加了判断是否转账方已经接受方账户被冻结的函数。

  function _transfer(address _from, address _to, uint _value) internal {
      require (_to != 0x0);                               // Prevent transfer to 0x0 address. Use burn() instead
      require (balanceOf[_from] > _value);                // Check if the sender has enough
      require (balanceOf[_to] + _value > balanceOf[_to]); // Check for overflows
      require(!frozenAccount[_from]);                     // Check if sender is frozen
      require(!frozenAccount[_to]);                       // Check if recipient is frozen
      balanceOf[_from] -= _value;                         // Subtract from the sender
      balanceOf[_to] += _value;                           // Add the same to the recipient
      Transfer(_from, _to, _value);
  }

之后,合约拥有者可以调用下面的函数来增加某个账户代币的数量。PS:这里我觉得是为了合约的健壮性考虑。合约的owner需要有足够的能力去增删改查所有用户的token数量。

之后增加金额后会将总金额-totalSupply进行更新。

/// @notice Create `mintedAmount` tokens and send it to `target`
  /// @param target Address to receive the tokens
  /// @param mintedAmount the amount of tokens it will receive
  function mintToken(address target, uint256 mintedAmount) onlyOwner {
      balanceOf[target] += mintedAmount;
      totalSupply += mintedAmount;
      Transfer(0, this, mintedAmount);
      Transfer(this, target, mintedAmount);
  }

除了上述增加token外,合约还定义了burn函数。

  /// @notice Remove `_value` tokens from the system irreversibly
  /// @param _value the amount of money to burn
  function burn(uint256 _value) returns (bool success) {
      require (balanceOf[msg.sender] > _value);            // Check if the sender has enough
      balanceOf[msg.sender] -= _value;                      // Subtract from the sender
      totalSupply -= _value;                                // Updates totalSupply
      Burn(msg.sender, _value);
      return true;
  }

这个函数的含义我还没有搞懂,但是从函数内容来看,它是用于销毁账户账面的部分金额。(就是说账户里有10块钱,我可以调用此函数来永久销毁2块钱)。

为了彰显owner的绝对权力,我们合约中能够查看到冻结账户的函数。

/// @notice `freeze? Prevent | Allow` `target` from sending & receiving tokens
  /// @param target Address to be frozen
  /// @param freeze either to freeze it or not
  function freezeAccount(address target, bool freeze) onlyOwner {
      frozenAccount[target] = freeze;
      FrozenFunds(target, freeze);
  }

合约的owner可以调用这个函数来冻结或者解冻账户,被冻结了的账户是无法进行转账操作的。

2 合约盲点

在我细致的分析合约过程中,我发现了合约中不易理解的一个点:
mapping (address => mapping (address => uint256)) public allowance;

合约定义了一个mapping变量,而这个变量存储的也是账户账面的金额数量。虽然这次漏洞中与这个变量没有太大的关系,但是为了给读者提供一个可参考的例子,我还是在这里对这个变量的作用进行分析。

简单来说,我认为这个变量就类似于我们生活中的工资的概念。而这个工资是使用的公司内部自己印刷的钱财,可以在公司内部进行交易转账等等。

首先我们可以看赋权函数:

  function approve(address _spender, uint256 _value)
      returns (bool success) {
      allowance[msg.sender][_spender] = _value;
      return true;
  }

这个函数使调用方给予_spender一个代替转账的权利。即 B向C转账,但是由于A给予B某些权利,那么我B就可以使用A给的额度来变相的向C转账。于是可以调用下面的转账函数:

function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
      require (_value < allowance[_from][msg.sender]);     // Check allowance
      allowance[_from][msg.sender] -= _value;  
      _transfer(_from, _to, _value);
      return true;
  }

所以C确实收到了钱,而B使用AB花费了的某些约定来进行支付。

除此之外,合约同样定义了销毁函数burnFrom。用于销毁AB直接的某些约定。

  function burnFrom(address _from, uint256 _value) returns (bool success) {
      require(balanceOf[_from] >= _value);                // Check if the targeted balance is enough
      require(_value <= allowance[_from][msg.sender]);    // Check allowance?????????????????????????????
      balanceOf[_from] -= _value;                         // Subtract from the targeted balance
      allowance[_from][msg.sender] -= _value;             // Subtract from the sender's allowance
      totalSupply -= _value;                              // Update totalSupply
      Burn(_from, _value);
      return true;
  }

3 安全漏洞点

阐述完了合约中的一些细节部分,下面我们来进一步对合约中存在的安全漏洞进行分析。

用户在合约中可以使用以太币来对合约中自定义的token进行兑换。

 /// @notice Buy tokens from contract by sending ether
  function buy() payable {
      uint amount = msg.value / buyPrice;               // calculates the amount
      _transfer(this, msg.sender, amount);              // makes the transfers
  }

用户可以传入value来购买数量为msg.value / buyPrice的token。而这个具体的单价是由合约拥有者调用函数得到的。

function setPrices(uint256 newSellPrice, uint256 newBuyPrice) onlyOwner {
      sellPrice = newSellPrice;
      buyPrice = newBuyPrice;
  }

之后,当用户有了足够的token后,他可以用token换回自己的以太币。即出售token。

function sell(uint256 amount) {
      require(this.balance >= amount * sellPrice);      // checks if the contract has enough ether to buy
      _transfer(msg.sender, this, amount);              // makes the transfers
      msg.sender.transfer(amount * sellPrice);          // sends ether to the seller. It's important to do this last to avoid recursion attacks
  }

而漏洞就在上面的函数中。因为买卖的单价均可以由owner进行定义。倘若owner进行作恶,将单价设置为特殊的值,那么便可以达到意想不到的效果。例如:

管理员设置buyPrice = 1 ether, sellPrice = 2^255。即用户可以花1以太币购买一个token,然后可以以2^255的价格卖出。看起来很划算对吗?但是这样便产生了整数溢出。

倘若我们卖出两个token:amount * sellPrice = 2^256 。而我们这里为uint256类型,所以直接产生溢出,使变量为0 。也就是说,系统便可以不用花费任何一分钱就可以收入2个token,而用户直接白白损失了2个以太币。

除此之外,我们还可以简单地将卖出价格设置为0,这样同样使amount * sellPrice为0 。不过有可能无法使那些投机的用户上钩。

我们也可以对合约进行简单的部署。

image.png

之后传入参数:

image.png

成功后对买卖变量进行设置:

之后便可以使用第二个测试账户进行token的购买操作。

四、参考资料

本稿为原创稿件,转载请标明出处。谢谢。

首发于先知社区,https://xz.aliyun.com/t/3743
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,968评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,601评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,220评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,416评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,425评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,144评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,432评论 3 401
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,088评论 0 261
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,586评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,028评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,137评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,783评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,343评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,333评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,559评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,595评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,901评论 2 345

推荐阅读更多精彩内容