Hash Collisions and Front-Running Risk

Lines of code
<https://github.com/code-423n4/2023-10-ens/blob/ed47c841a19abd26681110a26ef03c446da2b6dd/contracts/ERC20MultiDelegate.sol#L15-L20&gt;

Vulnerability details
<https://github.com/code-423n4/2023-10-ens/blob/ed47c841a19abd26681110a26ef03c446da2b6dd/contracts/ERC20MultiDelegate.sol#L15-L20&gt;

• Salt Value in Proxy Deployment: The contract uses a salt value of 0 during the deployment of proxy delegator contracts. This introduces a significant security concern related to potential hash collisions. If multiple delegators attempt to deploy to the same address simultaneously, only one of these transactions will succeed, and the others will revert due to the creation of a contract with the same address. This creates the risk of a race condition where transactions may compete, resulting in unintended reverts. Confirmed this is possible due to usage of only salt and delegatee address as the uniqueness parameters. The salt value is constant, and if delegators/attacker delegates to same delegatee, then same proxy address will be created/used.

• Potential Front-Running Risk: In addition to hash collisions, there’s a potential front-running risk. An attacker may exploit this by guessing the salt value and front-running a deployment transaction to become the msg.sender. This could enable the attacker to approve themselves for unlimited tokens. Have not confirmed that this is actually possible.

Recommendations:

1. Unique and Randomized Salt Value: To mitigate hash collision risks, it’s advisable to use a unique and randomized salt value for each proxy contract deployment. This would help prevent multiple delegators from inadvertently reverting their transactions due to address conflicts.

2. Access Control for Proxy Deployment: Implement access control mechanisms to ensure that only authorized contracts, such as the ERC20MultiDelegate contract, can deploy proxy delegators. This can help prevent unauthorized contracts from interfering with proxy deployments.

Two or More Delegators Sharing a Delegator Proxy:

• Proxy Contract Creation: The current contract design may inadvertently allow two or more delegators to share the same delegator proxy contract when they delegate to the same delegatee. This is not the intended functionality, as each delegator should have a separate delegator proxy for each delegatee they are delegating to.

• Access Control: While some level of access control seems to exist, it’s essential to verify that unauthorized users cannot create or access delegator proxy contracts.

Recommendations:

1. Enforce Unique Proxy Contracts: Ensure that each delegator has a unique proxy contract for each delegatee they delegate to. This prevents multiple delegators from sharing the same proxy contract.

2. Robust Access Controls: Implement strong access control mechanisms to prevent unauthorized access to delegator proxy contracts, ensuring that only authorized delegators can interact with their respective proxy contracts.

Assessed type

Governance

The text was updated successfully, but these errors were encountered:

All reactions