Securify之旅1之TOD漏洞剖析

什么是TOD

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

如下是一个智能合约：给予解决了计算难题的用户相应的奖励。

• 场景一: 温和场景(Benign Scenario)
  假设T_o和T_u差不时间发送信息到Puzzle。其中，T_o是来自合约的所有者，他想更新提出方案的奖励值。T_u是来自提出解决方案的用户，他想通过方案得到奖励。那么，在这个时候，T_o和T_u的执行顺序会影响到提出方案的用户最终能获得多少奖励。
• 场景二: 恶意场景(Malicious Scenario)
  注意，从T_u被广播到T_u被记录在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