A lack of input validation of the _owner argument in both the constructor and setOwner functions could permanently lock the owner role, requiring a costly redeploy.
To resolve an incorrect owner issue, Uniswap would need to redeploy the factory contract and re-add pairs and liquidity.
Users might not be happy to learn of these actions, which could lead to reputational damage.
Certain users could also decide to continue using the original factory and pair contracts, in which owner functions cannot be called.
This could lead to the concurrent use of two versions of Uniswap, one with the original factory contract and no valid owner and another in which the owner was set correctly.
Trail of Bits identified four distinct cases in which an incorrect owner is set:
- Passing
address(0)to the constructor - Passing
address(0)to thesetOwnerfunction - Passing an incorrect address to the constructor
- Passing an incorrect address to the
setOwnerfunction.
Several improvements could prevent the four above mentioned cases:
1. Designate msg.sender as the initial owner, and transfer ownership to the chosen owner after deployment.
2. Implement a two-step ownership-change process through which the new owner needs to accept ownership.
3. If it needs to be possible to set the owner to address(0), implement a renounceOwnership function.
- ToB Audit Uniswap V3 Finding 1
- Data Validation
- Medium Severity
- Incorrect owner
- Redeploy Contract
- Owner = msg.sender
- Two-step Change
- Youtube Reference
- Medium Risk severity finding from ToB’s Audit of Uniswap V3