0x4non - `call()` should be used instead of `transfer()` on an address payable

[github-actions[bot]]

0x4non

medium

call() should be used instead of transfer() on an address payable

Summary

Vulnerability Detail

The transfer() and send() functions forward a fixed amount of 2300 gas. Historically, it has often been recommended to use these functions for value transfers to guard against reentrancy attacks. However, the gas cost of EVM instructions may change significantly during hard forks which may break already deployed contract systems that make fixed assumptions about gas costs. For example. EIP 1884 broke several existing smart contracts due to a cost increase of the SLOAD instruction.

Impact

The use of the deprecated transfer() function for an address will inevitably make the transaction fail when:

• The claimer smart contract does not implement a payable function.
• The claimer smart contract does implement a payable fallback which uses more than 2300 gas unit.
• The claimer smart contract implements a payable fallback function that needs less than 2300 gas units but is called through proxy, raising the call's gas usage above 2300.
• Additionally, using higher than 2300 gas might be mandatory for some multisig wallets.

Code Snippet

DODORouteProxy.sol#L152 payable(routeFeeReceiver).transfer(restAmount); DODORouteProxy.sol#L489 payable(msg.sender).transfer(receiveAmount); UniversalERC20.sol#L29 to.transfer(amount);

Tool used

Manual Review

Recommendation

Use call() instead of transfer(), but be sure to respect the CEI pattern and/or add re-entrancy guards, as several hacks already happened in the past due to this recommendation not being fully understood.

More info on; https://swcregistry.io/docs/SWC-134

[Attens1423]

https://github.com/DODOEX/dodo-route-contract/pull/5

[aktech297]

Though the changes look pretty straight forward, i would suggest to include test cases for re-entrency to all types swaps.

[hrishibhat]

Based on comments & discussions with the Senior: The fix looks good, additionally Senior suggests adding necessary re-reentrancy protection to relevant swap functions.