Security Snippets: #10

Did you know that in some cases cloneDeterministic(salt) can play a rough joke with your protocol? Take a look on the next snippet:

function deployNewPool(address token0, address token1, uint24 fee, bytes32 salt)
        external
        returns (PanopticPool newPoolContract)
    {
        // sort the tokens, if necessary:
        (token0, token1) = token0 < token1 ? (token0, token1) : (token1, token0);
        .
        .
        .
        // This creates a new Panoptic Pool (proxy to the PanopticPool implementation)
        // Users can specify a salt, the aim is to incentivize the mining of addresses with leading zeros
@>      newPoolContract = PanopticPool(POOL_REFERENCE.cloneDeterministic(salt));
        .
        .
        .
    }

    function cloneDeterministic(address implementation, bytes32 salt) internal returns (address instance) {
        /// @solidity memory-safe-assembly
        assembly {
            // Cleans the upper 96 bits of the `implementation` word, then packs the first 3 bytes
            // of the `implementation` address with the bytecode before the address.
            mstore(0x00, or(shr(0xe8, shl(0x60, implementation)), 0x3d602d80600a3d3981f3363d3d373d3d3d363d73000000))
            // Packs the remaining 17 bytes of `implementation` with the bytecode after the address.
            mstore(0x20, or(shl(0x78, implementation), 0x5af43d82803e903d91602b57fd5bf3))
@>          instance := create2(0, 0x09, 0x37, salt)
        }
        require(instance != address(0), "ERC1167: create2 failed");
    }

As shown above, salt is a user-supplied parameter. By brute-forcing many salt values, we have obtained many different (undeployed) wallet accounts. The user can know the address of the Panoptic Pool before deploying it, since as shown in the above code snippet, the result is deterministic.

An attacker can find any single address collision with high probability of success using the meet-in-the-middle technique, a classic brute-force-based attack in cryptography.

Assuming the attacker has already found an address collision against an undeployed Panoptic Pool, let’s say 0xCOLLIDED. The steps for complete draining of the Panoptic Pool are as follow:

First tx:

1. Deploy the attack contract onto address 0xCOLLIDED.
2. Set infinite allowance for {0xCOLLIDED ---> attacker wallet} for any token they want.
2. Destroy the contract using selfdestruct.

Post Dencun hardfork, selfdestruct is still possible if the contract was created in the same transaction. The only catch is that all 3 of these steps must be done in one tx.

The attacker now has complete control of any funds sent to 0xCOLLIDED.

Second tx:

1. Deploy the Panoptic Pool to 0xCOLLIDED.
2. Wait until the Panoptic Pool will hold as many tokens as you want and drain it.

The attacker has stolen all funds from the Panoptic Pool.

As a recomendation to fix this issue, a developer shoul consider adding and encoding block.timestamp and block.number combined with the user’s salt. Then the attacker, after they successfully found a hash collision, already has to execute the attack at a fixed block and probably conspire with the sequencer to ensure that also the time is fixed.

Link: https://code4rena.com/reports/2024-04-panoptic#m-03-create2-address-collision-during-pool-deployment-allows-for-complete-draining-of-the-pool