Axelar Network - UniversalCrypto's results

Lines of code

https://github.com/code-423n4/2023-07-axelar/blob/2f9b234bb8222d5fbe934beafede56bfb4522641/contracts/interchain-governance-executor/InterchainProposalExecutor.sol#L73-L84

Vulnerability details

Impact

Cross-chain proposals can have value attached to them, however neither InterchainProposalExecutor or AxelarExecutable (which exposes the execute function) can receive either.

However _executeProposal tries to send value without having any way to receive any ether (bool success, bytes memory result) = call.target.call{ value: call.value }(call.callData);

Proof of Concept

Here you can see _executeProposal makes a call which intends to send ether

function _executeProposal(InterchainCalls.Call[] memory calls) internal { // @audit-issue AxelarExecutable isn't payable
        for (uint256 i = 0; i < calls.length; i++) {
            InterchainCalls.Call memory call = calls[i];
            (bool success, bytes memory result) = call.target.call{ value: call.value }(call.callData);

            if (!success) {
                _onTargetExecutionFailed(call, result);
            } else {
                _onTargetExecuted(call, result);
            }
        }
    }

This is called from _execute which isn't payable.

Neither is AxelarExecutable - execute

Neither AxelarExecutable nor InterchainProposalExecutor contain or inherit a receive or fallback payable to receive ether

Tools Used

manual

Recommended Mitigation Steps

Make AxelarExecutable - execute payable or implement a receive function to allow the call in _executeProposal to send ether

Assessed type

Payable

Lines of code

https://github.com/code-423n4/2023-07-axelar/blob/2f9b234bb8222d5fbe934beafede56bfb4522641/contracts/interchain-governance-executor/InterchainProposalExecutor.sol#L49-L51

Vulnerability details

Impact

InterchainProposalExecutor uses _execute for incoming cross-chain proposals. This function uses a custom library to convert the incoming string calldata sourceAddress to an address using toAddress. However toAddress assumes the incoming string is formatted like an EVM address and will revert if this is not the case, meaning the incoming proposal will fail.

Proof of Concept

toAddress

function toAddress(string memory addressString) internal pure returns (address) {
        bytes memory stringBytes = bytes(addressString);
        uint160 addressNumber = 0;
        uint8 stringByte;

        if (stringBytes.length != 42 || stringBytes[0] != '0' || stringBytes[1] != 'x') revert InvalidAddressString();

        for (uint256 i = 2; i < 42; ++i) {
            stringByte = uint8(stringBytes[i]);

            if ((stringByte >= 97) && (stringByte <= 102)) stringByte -= 87;
            else if ((stringByte >= 65) && (stringByte <= 70)) stringByte -= 55;
            else if ((stringByte >= 48) && (stringByte <= 57)) stringByte -= 48;
            else revert InvalidAddressString();

            addressNumber |= uint160(uint256(stringByte) << ((41 - i) << 2));
        }
        return address(addressNumber);
    }

Here you can see if the incoming addressString doesn't start with 0x or isn't of the correct length the call will revert.

Tools Used

Manual

Recommended Mitigation Steps

Ensure all incoming addresses from non-evm chains are dispatched in the correct format to be received

Assessed type

DoS