Improper Address Alignment in to_address Function Leading to Potential Address Spoofing[AddressCast.sol::to_address()]

[howlbot-integration]

Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/handler/contracts/libraries/AddressCast.sol#L14-L18

Vulnerability details

Impact

This vulnerability allows incoming bytes32 addresses to not be checked or processed in the expected format. The contract does not verify whether the address is aligned on the left or right end, resulting in potential incorrect address conversion. An attacker may manipulate the contract logic by forging bytes32 addresses, causing invalid addresses to be considered valid, thereby affecting key functions of the contract, such as fund transfer or permission verification.

Proof of Concept

Link1: https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/handler/contracts/libraries/AddressCast.sol#L14-L18

Link2: https://github.com/code-423n4/2024-08-chakra/blob/d0d45ae1d26ca1b87034e67180fac07ce9642fd9/solidity/settlement/contracts/libraries/AddressCast.sol#L22-L26

This function directly converts bytes32 to address, but does not verify whether the address in bytes32 is aligned on the correct side. Since Solidity addresses are of type uint160 and bytes32 is of type uint256, if the user does not strictly follow the correct alignment, the bytes32 type address conversion will fail if the address is left-aligned, leading to serious security issues.

Steps to reproduce:

• If the user's address is: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4
• The user encapsulates the address into bytes32 type in the following way:

    function convertAddreeToBytes32() external view returns(address) {
        uint160 ms = uint160(msg.sender);
        bytes32 res = bytes32(bytes20(ms));
        return AddressCast.to_address(res);
    }

• The output result is: 0x3fCb875F56bEDdc4000000000000000000000000

From the results, we can see that after the conversion by the to_address(bytes32 _address) function, the caller msg.sender and the output result are completely different, which is absolutely not allowed.

Tools Used

• Manual analysis
• Remix IDE

Recommended Mitigation Steps

To prevent this vulnerability, you need to check whether bytes32 conforms to the valid uint160 address format during address conversion and specify the alignment of the address in bytes32 data. This can be fixed by:

• Verify that the incoming bytes32 data is aligned on the left or right before doing address conversion.

    function to_address(
        bytes32 _address
    ) internal pure returns (address result) {
        require(uint256(_address) <= type(uint160).max, "Invalid address format");
        result = address(uint160(uint256(_address)));
    }

Assessed type

Decimal

[alex-ppg]

The Warden and its duplicates have identified that a potential truncation may occur when casting an input bytes32 representation of an address to its address format.

The documentation of the project is insufficient and does not permit validation of whether this particular issue is exploitable. All function paths that invoke the function will perform indirect validation of data corruption by generating a transaction hash based on the full bytes32 value, causing signature / data validation to fail if someone attempts to exploit the truncation described.

As such, I am inclined to consider this a QA-level observation rather than an actual vulnerability as no exploitable attack vector has been demonstrated.

[c4-judge]

alex-ppg changed the severity to QA (Quality Assurance)

[c4-judge]

alex-ppg marked the issue as grade-b