Full Report
In Solidity smart contract, there are two ways opcodes that can deploy contracts: CREATE and CREATE2. CREATE uses the addresses incrementing nonce in order to determine the address. CREATE2 takes in a user controlled value in order to determine where to place the contract. A network reorganization is when the blockchain ordering has changed somehow. This happens in a few cases: Network lag A fork of the chain Malicious actor messing with the system The smart contract being tested had functionality that would deploy a smart contract called a Quest when called. This contract used the CREATE in order to send this transaction. The author of this finding (solo medium severity finding) brings up a scenario with reordering and deterministic creation of a smart contract. A user may have a local script to create the quest that waits for the success to occur. After this succeeds, this would send funds to the contract. What if a reorganization occurred at this moment? A malicious actor could create the quest first! Then, the quest they created would be at a different location and their reassurance of the address would be gone. This means that the user would send their funds to the wrong contract. The author mentions that a user may try to predict the contract address and send the funds there. If this is true, then a simple frontrunning attack would work on them as well. The solution to this issue is to use the CREATE2 opcode instead. Overall, a weird finding that I'm sure could be reported more.
Analysis Summary
# Vulnerability: Reorganization Attack Leading to Misdirected Funds via `CREATE` Opcode
## CVE Details
- CVE ID: N/A (This is a finding from a code audit, not a publicly assigned CVE)
- CVSS Score: N/A (Severity assessed locally as Medium Risk)
- CWE: CWE-362 (Race Condition) is conceptually related, or potentially CWE-823 (Improper Restriction of Operations Within the Bounds of a Memory Buffer) in terms of predictable state manipulation.
## Affected Systems
- Products: Smart contracts utilizing the `QuestFactory` contract (specifically the logic within `createQuest`).
- Versions: Versions of the `QuestFactory` contract using `CREATE` opcode for deployment, as found in the `rabbitholegg/quest-protocol` repository at the time of the audit.
- Configurations: Deployment on networks susceptible to chain reorganizations (e.g., Polygon, Optimism, Arbitrum).
## Vulnerability Description
The `QuestFactory` contract uses the `CREATE` opcode to deploy "Quest" contracts. The address of the newly deployed contract is determined deterministically based on the deploying contract's address and its internal nonce.
This deterministic nature, when combined with network reorganizations (reorgs), presents a vulnerability:
1. **Prediction/Deployment:** A user or malicious actor might predict (or wait for the confirmation of) a deployment transaction, thus fixing the expected contract address. They might then send funds to this predicted address.
2. **Reorganization Effect:** If a chain reorganization occurs immediately after the deployment transaction is confirmed but before subsequent dependent transactions (like fund transfers) are finalized in the new canonical chain, the order of transactions can change.
3. **Race Condition:** A malicious actor who initiates a quest deployment *before* the victim's transaction (or one that causes a differing nonce state) can result in their newly created quest occupying the address the victim expected. If the victim then sends funds based on the *old* expected address, those funds are sent to the malicious actor’s controlled quest, leading to fund theft.
The vulnerability is exacerbated if users rely on address predictability, which can also be exploited via simple frontrunning attacks if prediction is possible.
## Exploitation
- Status: PoC conceptualized; attack relies on exploiting network latency/reorg susceptibility.
- Complexity: Medium (Requires timing an attack around potential reorg windows or race conditions).
- Attack Vector: Network (Exploiting block ordering and network instability/latency).
## Impact
- Confidentiality: None (No sensitive data leakage implied).
- Integrity: High (Funds can be directed to an attacker-controlled address).
- Availability: Low (Functionality of creating quests might be impacted by failed transfers, but core protocol availability seems intact).
## Remediation
### Patches
The recommended fix is to switch the deployment mechanism from `CREATE` to `CREATE2`.
- Specific implementation details require modifying the `QuestFactory.sol` to use `CREATE2` with a `salt` that includes unique user-specific data (e.g., `msg.sender` and `rewardTokenAddress_`).
### Workarounds
- Users should avoid sending funds to a predicted contract address until several blocks have confirmed the deployment transaction and chain history is stable, especially on chains known to experience reorgs.
- Developers should delay dependent transactions that rely on newly created addresses until greater finality is achieved.
## Detection
- Indicators of Compromise: Transactions sending funds to contracts immediately following a predictable deployment, especially if the deployment transaction source address is suspicious or if the deployment was followed shortly by a chain reorganization.
- Detection methods and tools: Monitoring deployment patterns on chains known for instability (like Polygon mainnet, as referenced) and analyzing transaction ordering robustness.
## References
- Vendor advisories: N/A (This is an audit finding from code423n4/2023-01-rabbithole-findings).
- Relevant links - defanged:
- github dot com/rabbitholegg/quest-protocol/blob/8c4c1f71221570b14a0479c216583342bd652d8d/contracts/QuestFactory.sol#L75
- github dot com/code-423n4/2023-01-rabbithole-findings/issues/661