breakdown of potential vulnerabilities and exploitation
Vulnerability Analysis
1. Owner Centralization Risks:
* **Parameter Manipulation:** The owner's ability to set critical parameters like `minDepositAmount`, `maxDepositAmount`, `governanceFee`, and `lockTime` could be abused. For example, the owner could drastically increase the `governanceFee` or `lockTime` to unfairly extract value or lock user funds.
* **Emergency State Abuse:** The owner can set the vault state in emergency situations. A malicious owner could trigger a false emergency to freeze funds or manipulate the system.
* **GMX Proxy and KeeperProxy Control:** The owner's control over GMX and Keeper proxy settings, including contract addresses and price feed parameters, presents a significant centralization risk. A compromised owner could direct funds to malicious addresses or manipulate price feeds.
2. **Keeper Dependency:**
* **Keeper Failure/Malice:** The protocol's reliance on a single keeper creates a single point of failure. A malfunctioning or malicious keeper could delay or prevent critical operations, leading to losses.
* **Gas Assumptions:** While the document states that the assumption is that there is always enough gas, in reality, there are many situations where this is not the case. A keeper can run out of gas, or external conditions can skyrocket gas prices.
* **Front-Running:** The keeper's execution of trades opens the door to front-running. A malicious keeper could observe pending transactions and execute their own trades to profit at the expense of users.
3. **Price Oracle Risks:**
* **Oracle Manipulation:** Although Chainlink is used, the owner's control over price feed settings and thresholds could lead to manipulation. An attacker who gains control of the owner's keys could manipulate these settings to trigger false liquidations or other adverse events.
* **Oracle Failure:** Chainlink, while robust, is not immune to failures. If the oracle fails to provide accurate prices, the protocol could make incorrect trading decisions.
4. **Withdrawal and Deposit Vulnerabilities:**
* **DoS Through Deposit/Withdrawal:** Even with the `minDepositAmount` of 1000, a coordinated attack could still flood the contract with deposit/withdrawal requests, causing a DoS. This could be used to manipulate the market or prevent legitimate users from accessing their funds.
* **Funding Fee Discrepancies:** The invariant regarding fair share of funding fees has an exception for users withdrawing before fees can be claimed. This could be exploited by rapidly depositing and withdrawing to manipulate fee distribution.
5. **Multi-Step Actions and Reentrancy:**
* **`runNextAction()` Manipulation:** The multi-step actions executed by the keeper could be vulnerable to manipulation. If an attacker can interrupt or manipulate the sequence of actions, they could potentially steal funds or disrupt the protocol.
* **Reentrancy Attacks:** While reentrancy guards are in place, a complex system like this could have edge cases where reentrancy is still possible, especially in interactions with external protocols like GMX and Paraswap.
6. **GMX Integration Risks:**
* **GMX Vulnerabilities:** The protocol's heavy reliance on GMX means that any vulnerabilities in GMX could directly impact the protocol.
* **Address Updates:** The owner's ability to update GMX-related addresses creates a risk of funds being directed to malicious contracts.
7. **Lack of Input Validation:**
* It is very important to verify that all inputs from the user, and from external contracts, are checked for correctness. Lack of input validation can lead to unexpected behavior.
**II. Exploitation Strategies**
1. **Owner Compromise:**
* If an attacker gains control of the owner's private keys, they can:
* Drain funds by updating contract addresses.
* Manipulate price feeds to trigger liquidations.
* Freeze funds by setting the vault state to an emergency.
* Extract excessive fees by increasing `governanceFee`.
2. **Keeper Manipulation:**
* A malicious keeper can:
* Front-run user transactions.
* Delay or prevent critical operations.
* Manipulate trade execution to profit.
* Run out of gas during critical operations.
3. **DoS Attacks:**
* Flood the contract with deposit/withdrawal requests to prevent legitimate users from accessing the protocol.
* Create many positions, and then trigger many withdrawals.
4. **Funding Fee Manipulation:**
* Rapidly deposit and withdraw to manipulate the distribution of funding fees.
5. **Oracle Manipulation:**
* If the owner's keys are compromised, manipulate price feed settings to trigger false liquidations.
* Attempt to cause the oracle to fail by any means possible.
**III. Recommendations**
1. **Decentralize Ownership:** Implement a multi-signature wallet or a decentralized governance mechanism to reduce the risks associated with a single owner.
2. **Keeper Redundancy:** Implement multiple keepers to reduce the risk of a single point of failure.
3. **Input Validation:** Thoroughly validate all user inputs and external contract interactions.
4. **Rate Limiting:** Implement rate limiting on deposit and withdrawal requests to mitigate DoS attacks.
5. **Circuit Breakers:** Implement circuit breakers to automatically pause the protocol in case of critical failures or price deviations.
6. **Thorough Testing:** Conduct extensive fuzz testing and formal verification to identify and eliminate potential vulnerabilities.
7. **Monitoring and Alerts:** Implement robust monitoring and alerting systems to detect anomalies and potential attacks.
By focusing on these areas, we can uncover critical vulnerabilities and help improve the security of the Gamma Strategies protocol.
Lead Judging Commences
Informational or Gas
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Admin is trusted / Malicious keepers
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."
Suppositions
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Informational or Gas
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
Admin is trusted / Malicious keepers
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."
Suppositions
There is no real proof, concrete root cause, specific impact, or enough details in those submissions. Examples include: "It could happen" without specifying when, "If this impossible case happens," "Unexpected behavior," etc. Make a Proof of Concept (PoC) using external functions and realistic parameters. Do not test only the internal function where you think you found something.
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.