Securify之旅1之TOD漏洞剖析

什么是TOD

TOD的英文全称是:Transaction-Ordering Dependence。一个block包含一个transaction的集合,同属于一个block的transaction的执行顺序是不确定的(只有矿工可以确定)。因此,也就导致了block的状态是不确定的。假设block处于状态σ,其中包含了两个transaction T1和T2。T1和T2又同时调用了同一个合约。那么,在这个时候,用户是无法知道这个合约的状态的,因为这取决于T1和T2的实际执行顺序。

如下是一个智能合约:给予解决了计算难题的用户相应的奖励。
Securify之旅1之TOD漏洞剖析_第1张图片

  • 场景一: 温和场景(Benign Scenario)
    假设To和Tu差不时间发送信息到Puzzle。其中,To是来自合约的所有者,他想更新提出方案的奖励值。Tu是来自提出解决方案的用户,他想通过方案得到奖励。那么,在这个时候,To和Tu的执行顺序会影响到提出方案的用户最终能获得多少奖励。
  • 场景二: 恶意场景(Malicious Scenario)
    注意,从Tu被广播到Tu被记录在block之间,有12s的时间间隔。也就是说,Puzzle合约的所有者可以一直保持监听网络,看是否有人提到解决方案到Puzzle。一旦有,他就发送一个transaction去更新奖励(比如设为一个很小的数)。在这种情况下,合约的所有者就很有可能(注意,并非一定)通过很小的花费就得到了解决方案。

漏洞根因

这个漏洞明显是由于区块链的不可能三角所致:满足去中心与可扩展性的前提下,不可能再满足安全性。再讲白些:交易要在众多分布式节点间共识,肯定要一定的时间;在这较长的时间里,为了提高区块链网络的服务吞吐能力,肯定在一个区块里接收多笔交易;而不同的节点接收到具体的交易时间先后顺序没有办法保证,因此交易在一个区块里执行的先后顺序就没有办法保证,因此若干个基于同一个合约的交易,如发生在同一个区块内,是没有办法确定这个合约的状态的。

如何防御

对于与区块链的漏洞,最好的防御手段,就是把它检测出来,并杜绝此类同一区块里,对状态改变的场景出现。
如果是要让用户接受这种状态变更,那也应在相应状态的设置变更上,设置更强的访问控制逻辑。比如在上面的例子中,就是对Reward数额的修改,就不仅要求合约的Owner许可,还应加入利益的其它方(像为Puzzle提供解决方案的用户,起码是绝大多数用户)的许可。
注:上面代码中想要通过处理流程加锁的机制,来相关状态变更的同步,是不行的;因为这种同步,并不能控制区块链中区块中交易的先后。

参考

  1. [Principles of Security and Trust’17]A Survey of Attacks on Ethereum Smart Contracts (SoK)
  2. [CCS’16]Making Smart Contracts Smarter
  3. https://www.cnblogs.com/XBWer/p/9697361.html#8

你可能感兴趣的:(区块链安全工具,区块链,智能合约,安全性测试,安全)