TOB-FUEL-7: Merkle tree proof parameters could be malleable

[Green Baneling]

Description

Some parameters that are used in the merkle tree proofs are malleable for certain parts of the proof.
The serializeConsensusHeader function in the FuelERC20Gateway truncates the header.height of type uint64 to a uint32.

Figure 7.1: The serializeConsensusHeader function in fuel-v2-contracts/contracts/fuelchain/types/FuelBlockHeader.sol

function serializeConsensusHeader(FuelBlockHeader memory header) internal pure returns (bytes memory) {
    return
        abi.encodePacked(
            header.prevRoot,
            (uint32)(header.height),
            header.timestamp,
            computeApplicationHeaderHash(header)
        );
}

This means that the upper bits are malleable and changing them will result in the same hash. We were, however, not able to identify an attack vector.
In a similar manner, message.recipient is being truncated from bytes32 to address (20 bytes) in _executeMessage.

Figure 7.2: Snippet from the _executeMessage function in fuel-v2-contracts/contracts/fuelchain/FuelMessagePortal.sol

function _executeMessage(bytes32 messageId, Message calldata message) private nonReentrant {
    require(!_incomingMessageSuccessful[messageId], "Already relayed");

    //set message sender for receiving contract to reference
    _incomingMessageSender = message.sender;

    //relay message
    //solhint-disable-next-line avoid-low-level-calls
    bool success = SafeCall.call(
        address(uint160(uint256(message.recipient))),
        message.amount * (10 ** (ETH_DECIMALS - FUEL_BASE_ASSET_DECIMALS)),
        message.data
    );

In this case, changing the recipient bits would change the messageId required for the inclusion proof, meaning that this is not vulnerable in its current form.
We highlight these cases nonetheless, because changing code requirements and specifications can lead to mistakes.

Recommendations

Short term, do not truncate header.height and check that the upper bits for the message.recipient are zero.
Long term, aim to minimize any degrees of freedom that a user has on the system that could lead to a vulnerability.