Rust 智能合约养成日记: 合约安全之重入攻击

往期回顾：

这一期中我们将向大家展示Rust合约中重入攻击，并提供给开发者相应的建议。本文中的相关代码，已上传至BlockSec的Github上，读者可以自行下载：https://github.com/blocksecteam/near_demo

我们用现实生活中的简单例子来理解重入攻击：即假设某用户在银行中存有100元现金，当用户想要从银行中取钱时，他将首先告诉柜员-A：“我想要取60元”。柜员-A此时将查询用户的余额为100元，由于该余额大于用户想要取出的数额，所以柜员-A首先将60元现金交给了该位用户。但是当柜员-A还没有来得及将用户的余额更新为40元的时，用户跑去隔壁告诉另一位柜员-B：“我想要取60元”，并隐瞒了刚才已经向柜员-A取钱的事实。由于用户的余额还没有被柜员-A更新，柜员-B检查用户的余额仍旧为100元，因此柜员-B将毫不犹豫地继续将60元交给用户。最终用户实际已经获得了120元现金，大于之前存在银行中的100元现金。

为什么会发生这样的事情呢？究其原因还是因为柜员-A没有事先将用户的60元从该用户的账户中扣除。若柜员-A能事先扣除金额。用户再询问柜员-B取钱时，柜员-B就会发现用户的余额已更新，无法取出比余额(40元)更多的现金了。

以上述“从银行取钱”这一典型过程为例，映射到具体的智能合约世界中来，实际上跨合约调用行为的发生和真正更新本地所维护的合约数据之间也同样地存在一定的时间间隔。而该时间间隔的存在以及这两个步骤之前不恰当的顺序关系，将给攻击者实施重入攻击创造有利条件。

下文第2小节将首先介绍相关的背景知识，第3小节将在NEAR LocalNet中演示说明一个具体的重入攻击例子，以体现代码重入对于部署在NEAR链上的智能合约的危害性。本文最后将具体介绍针对重入攻击的防护技术，帮助大家更好的编写Rust智能合约。

NEP141为NEAR公链上的Fungible Token （以下均用Token简称）标准 。大部分NEAR上的Token都遵循NEP141标准。

当某一用户想要从某一个Pool中，如去中心化交易所 （DEX）, 充值(deposite)或者提现(withdraw)一定数额的Token时，用户便可以调用相应的合约接口完成具体的操作。

DEX项目合约在执行所对应的接口函数时，将调用Token合约中的ft_transfer/ft_transfer_call函数，实现正式的转账操作。这两个函数的区别如下：

而对于ft_transfer_call而言，该方法内部除了首先会扣除该笔交易发起者(sender_id)的转账数额，并增加受转账用户(receiver_id)的余额，此外还额外增加了对receiver_id合约中ft_on_transfer(收币函数)的跨合约调用。这里可以简单理解为，此时Token合约将提醒receiver_id合约，有用户存入了指定数额的Token。receiver_id合约将在ft_on_transfer函数中自行维护内部账户的余额管理。

假设存在如下3个智能合约：

#[near_bindgen]#[derive(BorshDeserialize, BorshSerialize)]pub?struct?VictimContract?{attacker_balance:?u128,other_balance:?u128,}?impl?Default?for?VictimContract?{fn?default()?->?Self?{Self?{attacker_balance:?100,other_balance:100}}}

合约C: Token合约 （NEP141）。

攻击发生前，因为Attacker账户没有从Victim合约提现，所以余额为0，此时Victim合约(DEX)的余额为100+100 =200；

#[near_bindgen]#[derive(BorshDeserialize, BorshSerialize)]pub?struct?FungibleToken?{attacker_balance:?u128,victim_balance:?u128}?impl?Default?for?FungibleToken?{fn?default()?->?Self?{Self?{attacker_balance:?0,victim_balance:?200}}?

下面描述该代码重入攻击的具体流程：

例如此时Attacker给withdraw函数传入amount参数的值为60，希望从合约B中提现60；

impl?MaliciousContract?{pub?fn?malicious_call(&mut?self,?amount:u128){ext_victim::withdraw(amount.into(),?&VICTIM,?0,?env::prepaid_gas()?-?GAS_FOR_SINGLE_CALL);}...}

impl?VictimContract?{pub?fn?withdraw(&mut?self,amount:?u128)?->?Promise{assert!(self.attacker_balance>=?amount);// Call Attacker的收币函数ext_ft_token::ft_transfer_call(amount.into(),?&FT_TOKEN,?0,?env::prepaid_gas()?-?GAS_FOR_SINGLE_CALL?*?2).then(ext_self::ft_resolve_transfer(amount.into(),&env::current_account_id(),0,GAS_FOR_SINGLE_CALL,))}...}

通过上述代码中的ext_ft_token::ft_transfer_call实现跨合约调用。

#[near_bindgen]impl?FungibleToken?{pub?fn?ft_transfer_call(&mut?self,amount:?u128)->?PromiseOrValue<U128>{// 相当于 internal_ft_transferself.attacker_balance?+=?amount;self.victim_balance-=?amount;?// Call Attacker的收币函数ext_fungible_token_receiver::ft_on_transfer(amount.into(),?&ATTACKER,0,?env::prepaid_gas()?-?GAS_FOR_SINGLE_CALL).into()}...}

#[near_bindgen]impl?MaliciousContract?{pub?fn?ft_on_transfer(&mut?self,?amount:?u128){// 恶意合约的收币函数if?self.reentered?==?false{ext_victim::withdraw(amount.into(),?&VICTIM,?0,?env::prepaid_gas()?-?GAS_FOR_SINGLE_CALL);}self.reentered?=?true;}...}

最终执行的结果如下：

$ node?Triple_Contracts_Reentrancy.js?Finish init NEARFinish deploy contracts and create test accountsVictim::attacker_balance:3.402823669209385e+38FT_Token::attacker_balance:120FT_Token::victim_balance:80

即尽管用户Attacker在DEX中锁定的FungibleToken余额仅100，但是最终Attacker实际获得的转账为120，实现了本次代码重入攻击的目的。

4.1 先更新和与状态（先扣钱），再转账。

更改合约B代码 withdraw中的执行逻辑为：

#[near_bindgen]impl?VictimContract?{pub?fn?withdraw(&mut?self,amount:?u128)?->?Promise{assert!(self.attacker_balance>=?amount);self.attacker_balance?-=?amount;// Call Attacker的收币函数ext_ft_token::ft_transfer_call(amount.into(),?&FT_TOKEN,?0,?env::prepaid_gas()?-?GAS_FOR_SINGLE_CALL?*?2).then(ext_self::ft_resolve_transfer(amount.into(),&env::current_account_id(),0,GAS_FOR_SINGLE_CALL,))}

#[private]pub?fn?ft_resolve_transfer(&mut?self,?amount:?u128) {match?env::promise_result(0) {PromiseResult::NotReady?=>?unreachable!(),PromiseResult::Successful(_)?=>?{}PromiseResult::Failed?=>?{// 若ext_ft_token::ft_transfer_call跨合约调用转账失败，// 则回滚之前账户余额状态的更新self.attacker_balance?+=?amount;}};}

此时的执行效果如下：

$ node?Triple_Contracts_Reentrancy.js?Finish init NEARFinish deploy contracts and create test accountsReceipt: 873C5WqMyaXBFM3dmoR9t1sSo4g5PugUF8ddvmBS6g3XFailure [attacker.test.near]: Error: {"index":0,"kind":{"ExecutionError":"Smart contract panicked: panicked at 'assertion failed: self.attacker_balance >= amount', src/lib.rs:45:9"}}Victim::attacker_balance:40FT_Token::attacker_balance:60FT_Token::victim_balance:140

可见由于此时的Victim合约在withdraw的时候事先更新了用户的余额，在调用外部的FungibleToken实施转账。因此当第二次重入了withdraw的时候，Victim合约中保存的attacker_balance已经更新为40，因此将无法通过assert!(self.attacker_balance>= amount);使得Attcker的调用流程由于触发了Assertion Panic，无法利用代码重入进行套利。

4.2 引入互斥锁

该方法类似于当柜员-A还没有来得及将用户的余额更新为40元的时，用户跑去隔壁告诉另一位柜员-B：“我想要取60元”。尽管用户隐瞒了刚才已经向柜员-A取钱的事实。但是柜员-B却能够知道用户已经去过柜员-A那里，并且还没有办结所有的事项，此时柜员-B便可以拒绝用户来取钱。通常情况下可以通过引入一个状态变量，来实现一个互斥锁

4.3 设置Gas Limit

例如在DEX合约的withdraw方法调用ext_ft_token::ft_transfer_call时，设置一个适当的Gas Limit。此Gas Limit将不够支持下一次代码再次重入DEX合约的withdraw函数，以此阻断重入攻击的能力。

例如对代码做如下修改，限制withdraw方法调用外部函数时的Gas Limit:

pub?fn?withdraw(&mut?self,amount:?u128)?->?Promise{assert!(self.attacker_balance>=?amount);// Call Attacker的收币函数ext_ft_token::ft_transfer_call(amount.into(),?&FT_TOKEN,?0,?-env::prepaid_gas()?-?GAS_FOR_SINGLE_CALL?*?2+GAS_FOR_SINGLE_CALL?*?3).then(ext_self::ft_resolve_transfer(amount.into(),&env::current_account_id(),0,GAS_FOR_SINGLE_CALL,))}

修改后执行效果如下

$ node?Triple_Contracts_Reentrancy.jsFinish init NEARFinish deploy contracts and create test accountsReceipt: 5xsywUr4SePqfuotLXMragAC8P6wJuKGBuy5CTJSxRMXFailure [attacker.test.near]: Error: {"index":0,"kind":{"ExecutionError":"Exceeded the prepaid gas."}}Victim::attacker_balance:40FT_Token::attacker_balance:60FT_Token::victim_balance:140

可见限制跨合约函数调用时的Gas Limit也能起到防止重入攻击的效果。

这一期我们讲述了rust智能合约中的整数溢出问题，同时给出了建议，在书写代码时尽量先更新状态，再执行转账操作，并且设定合适的gas值，可以有效抵御重入攻击，下一期我们将讲述rust智能合约中的DoS问题，敬请关注。

—-

编译者/作者：BlockSec

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。