User can block another user safe creation #106
Labels
bug
Something isn't working
downgraded by judge
Judge downgraded the risk level of this issue
duplicate-443
grade-c
QA (Quality Assurance)
Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
satisfactory
satisfies C4 submission criteria; eligible for awards
Lines of code
https://github.com/re-nft/smart-contracts/blob/3ddd32455a849c3c6dc3c3aad7a33a6c9b44c291/src/policies/Factory.sol#L180-L186
Vulnerability details
Impact
The factory doesn't use any user-inputted salt. This opens the door for a DOS.
Proof of Concept
When the factory generates a safe, it uses the following Solidity code:
safeProxyFactory utilizes create2 (createProxyWithNonce -> deployProxy) with the aforementioned inputs. Here,
safeSingleton
is a constant address,initializerPayload
is predictable and constant for different users, and the "salt" is simply the number of safes incremented by one.Our attack specifically targets the salt. If we deploy a safe at an address where our victim is going to deploy it,
create2
will revert, leading to the victim's transaction reverting. This will not increase STORE.totalSafes(), meaning that the "salt" will remain the same. Subsequent transactions will also revert. The only way for our victim to deploy a safe is if someone else uses the Factory to deploy one.Example:
POC
Gist - https://gist.github.com/0x3b33/9baf7167e800b7a3b46b74ad3b12f982
Place in -
smart-contracts/test/unit/<name>.sol
Run with -
forge test --match-test test_FRfactory
Tools Used
Manual review and Джиджи, the gangster dog.
Recommended Mitigation Steps
Add a salt that the user can input, this way even if someone FR and reverts his TX, he can deploy another safe.
Assessed type
DoS
The text was updated successfully, but these errors were encountered: