08月08, 2018

EOS官方API中Asset结构体的乘法运算溢出漏洞描述

古河@360 Vulcan Team

综述

asset是EOS官方头文件中提供的用来代表货币资产(如官方货币EOS或自己发布的其它货币单位)的一个结构体。在使用asset进行乘法运算(operator *=)时,由于官方代码的bug,导致其中的溢出检测无效化。造成的结果是,如果开发者在智能合约中使用了asset乘法运算,则存在发生溢出的风险。

漏洞细节

问题代码存在于contracts/eosiolib/asset.hpp:

asset& operator*=( int64_t a ) {

         eosio_assert( a == 0 || (amount * a) / a == amount, "multiplication overflow or underflow" );                                  <== (1)

         eosio_assert( -max_amount <= amount, "multiplication underflow" );  <= (2)

         eosio_assert( amount <= max_amount,  "multiplication overflow" );   <= (3)

         amount *= a;

         return *this;

}

可以看到,这里官方代码一共有3处检查,用来防范溢出的发生。不幸的是,这三处检查没有一处能真正起到作用。 首先我们来看检查(2)和(3),比较明显,它们是用来检查乘法的结果是否在合法取值范围[-max_amouont, max_amount]之内。这里的问题是他们错误地被放置在了amouont = a这句代码之前,正确的做法是将它们放到amouont = a之后,因为它的目的是检测运算结果的合法性。正确的代码顺序应该是这样:

amount *= a;

eosio_assert( -max_amount <= amount, "multiplication underflow" );  <= (2)

eosio_assert( amount <= max_amount,  "multiplication overflow" );   <= (3)

下面来看检测(1),这是一个非常重要的检测,目的是确保两点: 1.乘法结果没有导致符号改变(如两个正整数相乘,结果变成了负数) 2.乘法结果没有溢出64位符号数(如两个非零正整数数相乘,结果比其中任意一个都小)

  eosio_assert( a == 0 || (amount * a) / a == amount, "multiplication overflow or underflow" );  <== (1)

这里的问题非常隐晦,直接看C++源代码其实看不出什么问题。但是我们要知道,EOS的智能合约最终是编译成webassembly字节码文件来执行的,让我们来看看编译后的字节码长什么样子:

  (call $eosio_assert

   (i32.const 1)    //  always true

   (i32.const 224)  // "multiplication overflow or underflow\00")

  )

上述字节码对应于源码中的:

  eosio_assert( a == 0 || (amount * a) / a == amount, "multiplication overflow or underflow" );  <== (1)

这个结果让我们非常吃惊,应为很明显,生成的字节码代表的含义是:

  eosio_assert(1, "multiplication overflow or underflow" );

相当于说这个assert的条件变成了永远是true,这里面的溢出检测就这样凭空消失了!!! 根据我们的经验,会发生这样的问题,很可能是编译器优化导致的。于是我们查看了一下官方提供的编译脚本(eosiocpp):

($PRINT_CMDS; /root/opt/wasm/bin/clang -emit-llvm **-O3** --std=c++14 --target
=wasm32 -nostdinc \

可以看到它是调用clang进行编译的,并且默认开启了编译器优化,优化级别是O3,比较激进的一个级别。 我们尝试关闭编译器优化(使用-O0),然后重新编译相同的代码,这次得到的对应字节码如下:

  (block $label$0

   (block $label$1

    (br_if $label$1

     (i64.eqz

      (get_local $1)

     )

    )

    (set_local $3

     (i64.eq

      (i64.div_s

       (i64.mul

        (tee_local $1

         (i64.load

          (get_local $0)

         )

        )

        (tee_local $2

         (i64.load

          (get_local $4)

         )

        )

       )

       (get_local $2)

      )

      (get_local $1)

     )

    )

    (br $label$0)

   )

   (set_local $3

    (i32.const 1)

   )

  )

  (call $eosio_assert

   (get_local $3)     **// condition based on "a == 0 || (amount * a) / a == amount"**

   (i32.const 192)   **//** **"multiplication overflow or underflow\00")**

可以看到这次生成的字节码中完整保留了溢出检测的逻辑,至此我们可以确定这个问题是编译器优化造成的。 为什么编译器优化会导致这样的后果呢?这是因为在下面的语句中,amount和a的类型都是有符号整数:

eosio_assert( a == 0 || (amount * a) / a == amount, "multiplication overflow or underflow" );

在C/C++标准中,有符号整数的溢出属于“未定义行为(undefined behavior)”。当出现未定义行为时,程序的行为是不确定的。所以当一些编译器(包括gcc,clang)做优化时,不会去考虑出现未定义行为的情况(因为一旦出现未定义行为,整个程序就处于为定义状态了,所以程序员需要自己在代码中去避免未定义行为)。简单来讲,在这个例子里面,clang在做优化时不会去考虑以下乘法出现溢出的情况:

(amount * a)

那么在不考虑上面乘法溢出的前提下,下面的表达式将永远为true:

a == 0 || (amount * a) / a == amount

于是一旦打开编译器优化,整个表达式就直接被优化掉了。

官方补丁

8月7日EOS官方发布了这个漏洞的补丁: https://github.com/EOSIO/eos/commit/b7b34e5b794e323cdc306ca2764973e1ee0d168f

漏洞的危害

由于asset乘法中所有的三处检测通通无效,当合约中使用asset乘法时,将会面临所有可能类型的溢出,包括:

  1. a > 0, b > 0, a * b < 0
  2. a > 0, b > 0, a * b < a
  3. a * b > max_amount
  4. a * b < -max_amount

响应建议

对于EOS开发者,如果您的智能合约中使用到了asset的乘法操作,我们建议您更新对应的代码并重新编译您的合约。因为像asset这样的工具代码是静态编译进合约中的,必须重新编译才能解决其中的安全隐患。 同时,我们也建议各位EOS开发者重视合约中的溢出问题,在编写代码时提高安全意识,避免造成不必要的损失。

时间线

2018-7-26: 360 Vulcan团队在代码审计中发现asset中乘法运算的溢出问题 2018-7-27: 通过Hackerone平台将漏洞提交给EOS官方 2018-8-7: EOS官方发布补丁修复漏洞

本文链接:http://blogs.360.cn/post/eos官方api中asset结构体的乘法运算溢出漏洞描述.html

-- EOF --

Comments