Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User can block another user safe creation #106

Closed
c4-bot-4 opened this issue Jan 15, 2024 · 3 comments
Closed

User can block another user safe creation #106

c4-bot-4 opened this issue Jan 15, 2024 · 3 comments
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

Comments

@c4-bot-4
Copy link
Contributor

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.createProxyWithNonce(
     address(safeSingleton),
     initializerPayload,
     uint256(keccak256(abi.encode(STORE.totalSafes() + 1, block.chainid)))
)

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:

  1. ProjectX is a competitor of re-NFT.
  2. It sees that Bob wants to rent a few NFTs.
  3. ProjectX front runs Bob's TX and deploys a safe on its to be deployment address.
  4. Bob's TX reverts.
  5. Bob does another TX, but it also reverts.
  6. Bob fires a third TX which also reverts, he quits.
  7. Bob rents NFTs at ProjectX's site.

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.

-   function deployRentalSafe(... , uint256 salt) external returns (address safe) {
+   function deployRentalSafe(... , uint256 salt) external returns (address safe) {
        ...
        safe = address(
            safeProxyFactory.createProxyWithNonce(
               address(safeSingleton),
               initializerPayload,
-              uint256(keccak256(abi.encode(STORE.totalSafes() + 1, block.chainid)))
+              uint256(keccak256(abi.encode(STORE.totalSafes() + 1, block.chainid, salt)))
            )
         ...
       );

Assessed type

DoS

@c4-bot-4 c4-bot-4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Jan 15, 2024
c4-bot-4 added a commit that referenced this issue Jan 15, 2024
@c4-pre-sort
Copy link

141345 marked the issue as duplicate of #443

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Jan 28, 2024
@c4-judge
Copy link
Contributor

0xean marked the issue as satisfactory

@c4-judge
Copy link
Contributor

0xean changed the severity to QA (Quality Assurance)

@c4-judge c4-judge added downgraded by judge Judge downgraded the risk level of this issue QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Jan 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
None yet
Development

No branches or pull requests

4 participants