Lines of code

https://github.com/code-423n4/2024-06-panoptic/blob/153f0d82440b7e63075d55b0659706531431145f/contracts/base/FactoryNFT.sol#L79 https://github.com/code-423n4/2024-06-panoptic/blob/153f0d82440b7e63075d55b0659706531431145f/contracts/base/FactoryNFT.sol#L58-L112

Vulnerability details

Impact

The toHexString function from the LibString library is being used to convert the panopticPool address to a hexadecimal string representation. However, the second argument passed to toHexString is 20, which specifies the desired length of the resulting string. FactoryNFT contract (@contracts\base\FactoryNFT.sol:79)

LibString.toHexString(uint256(uint160(panopticPool)), 20),

The problem is that an Ethereum address is 20 bytes long, which corresponds to 40 hexadecimal characters (each byte is represented by 2 hexadecimal digits). By passing 20 as the second argument, the function is requesting a string of only 20 characters, which is insufficient to represent the full address.

Proof of Concept

A relevant code snippet that illustrates the issue: FactoryNFT contract (@contracts\base\FactoryNFT.sol:58-112)

function constructMetadata(
    address panopticPool,
    string memory symbol0,
    string memory symbol1,
    uint256 fee
) public view returns (string memory) {
    // ...

    return
        string(
            abi.encodePacked(
                "data:application/json;base64,",
                Base64.encode(
                    bytes(
                        abi.encodePacked(
                            '{"name":"',
                            abi.encodePacked(
                                LibString.toHexString(uint256(uint160(panopticPool)), 20), // Incorrect length argument
                                "-",
                                // ...
                            ),
                            // ...
                        )
                    )
                )
            )
        );
}

As shown in the code, the toHexString function is called with 20 as the second argument, which is insufficient to represent the full Ethereum address.

Let's consider an example:

Suppose the panopticPool address is 0x1234567890123456789012345678901234567890. When passed to the toHexString function with a length of 20, the resulting string will be truncated to 0x1234567890123456789, which is only half of the actual address.

This truncated address will be included in the metadata URI, leading to the above mentioned issues. Any external systems or tools relying on the metadata may encounter difficulties in correctly identifying or interacting with the Panoptic Pool based on the incomplete address information.

Tools Used

Vs Code

Recommended Mitigation Steps

Change the second argument to 40 to ensure the entire address is properly represented as a hexadecimal string. By making this change, the toHexString function will return the full 40-character hexadecimal representation of the panopticPool address, avoiding any truncation or loss of information.

LibString.toHexString(uint256(uint160(panopticPool)), 40),

Assessed type

Other

code-423n4 / 2024-06-panoptic-findings

Incorrect String Truncation in FactoryNFT Can Lead to Incomplete Panoptic Pool Addresses Within Metadata URI #44