#38066 [SC-Medium] `ProxyFactory` is vulnerable to DoS/Address Hijacking

Submitted on Dec 23rd 2024 at 17:36:14 UTC by @holydevoti0n for Audit Comp | Lombard

  • Report ID: #38066

  • Report Type: Smart Contract

  • Report severity: Medium

  • Target: https://github.com/lombard-finance/evm-smart-contracts/blob/main/contracts/factory/ProxyFactory.sol

  • Impacts:

    • Block stuffing

    • Unbounded gas consumption

Description

Vulnerability Details

An attacker can front-run the createTransparentProxy call with the same salt but different constructor parameters (e.g., a different admin). This lets them deploy first and take the same final address the user intended to use. Once deployed, the address is no longer available to the legitimate user, causing denial of service or address hijacking.

contract ProxyFactory {
    function createTransparentProxy(
        address implementation,
        address admin,
        bytes memory data,
        bytes32 salt
    ) public returns (address) {
        bytes memory bytecode = abi.encodePacked(
            type(TransparentUpgradeableProxy).creationCode,
            abi.encode(implementation, admin, data)
        );

@>        address proxy = CREATE3.deploy(salt, bytecode, 0);
        return proxy;
    }
}

The main issue here is the following:

The factory is fully open; anyone can call it without restrictions. Deterministic deployment here depends only on (factoryAddress, salt, fixedProxyBytecode), not on constructor arguments. Using the same salt will always yield the same final address.

Thus, an attacker can prevent valid deployments or forcibly take over a deterministic address.

It could be worse if those contracts are somehow used/listed as the deployed addresses where it would lead users/governance to interact with.

Impact Details

  • DoS of contract's deployment through ProxyFactory.

  • Potential loss of funds if users/governance/devs interact with the contract.

Recommendation

Implement an access control modifier on createTransparentProxy.

Proof of Concept

Create a file called ProxyFactoryDos.ts inside the test folder.

Paste the code below and run: npx hardhat test test/ProxyFactoryDoS.ts

Output:

Here we proof that the attacker front-run the transaction and created a proxy with the same address using a different implementation.

Last updated

Was this helpful?