code-423n4 / 2022-07-axelar-findings

0 stars 0 forks source link

QA Report #169

Open code423n4 opened 2 years ago

code423n4 commented 2 years ago

[L-01] Unused receive() function will lock Ether in contract

Impact

If the intention is for the Ether to be used, the function should call another function, otherwise it should revert

deposit-service/DepositReceiver.sol:29:    receive() external payable {}
deposit-service/AxelarDepositServiceProxy.sol:13:    receive() external payable override {}

https://github.com/code-423n4/2022-07-axelar/tree/main/contracts/deposit-service/DepositReceiver.sol#L29 https://github.com/code-423n4/2022-07-axelar/tree/main/contracts/deposit-service/AxelarDepositServiceProxy.sol#L13

[L-02] approve is subject to a known front-running attack. Consider using safeApprove instead:

approve is subject to a known front-running attack. Consider using safeApprove instead:

deposit-service/ReceiverImplementation.sol:38:        IERC20(tokenAddress).approve(gateway, amount);
deposit-service/ReceiverImplementation.sol:64:        IERC20(wrappedTokenAddress).approve(gateway, amount);
deposit-service/AxelarDepositService.sol:30:        IERC20(wrappedTokenAddress).approve(gateway, amount);

Update to _token.safeApprove(spender, type(uint256).max) in the function.

re1ro commented 2 years ago

Dup #3

GalloDaSballo commented 2 years ago

[L-01] Unused receive() function will lock Ether in contract

AxelarDepositServiceProxy cannot sweep out, so valid L

[L-02] approve is subject to a known front-running attack. Consider using safeApprove instead:

Simply not true, both approve and safeApprove are subject to front-run of allowance changes, while the code will not be front-runnable if the gateway will move the tokens in the same tx in which the approval is done. For that reason I disagree.

1 L