Axelar Network v2 contest - cryptonue's results

Lines of code

https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/ReceiverImplementation.sol#L23 https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/ReceiverImplementation.sol#L51 https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/ReceiverImplementation.sol#L71 https://github.com/code-423n4/2022-07-axelar/blob/main/contracts/deposit-service/ReceiverImplementation.sol#L86

Vulnerability details

Using transfer() for ETH refund on ReceiverImplementation.sol

Impact

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

• The receiver smart contract does not implement a payable function.
• The receiver smart contract does implement a payable fallback which uses more than 2300 gas unit.
• The receiver 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.

More over, using higher than 2300 gas might be mandatory for some multisig wallets.

Proof of Concept

• Solidity’s transfer() and send() use a hardcoded gas amount.
• in ReceiverImplementation.sol, receiveAndSendToken(), receiveAndSendNative(), receiveAndUnwrapNative() functions are using transfer (with fixed stipend 2300 gas)
• if those receivers (refundAddress) are smart contract, there is possibility of failure, and then revert the transaction.
• The complete explanation of this issue can be seen in https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/ and https://chainsecurity.com/istanbul-hardfork-eips-increasing-gas-costs-and-more/
• Previous Code4rena report categorize this issue as medium risk. https://github.com/code-423n4/2022-05-backd-findings/issues/180

Recommended Mitigation Steps

Recommend using call() instead of transfer(), and make sure to check for reentrancy.