Full Report
Two parameters are used in order to prevent validators from holding onto transactions until it's convenient for them to spend. First, there is slippage. This is used in order to prevent a frontrunner giving you a bad price. In particular, you choose the minimum amount of tokens out that you're okay with. The second is the deadline. The transaction could wait in the mempool for a long time when trading is intense. Setting the maximum amount of time it waits in the transaction pool is important in order to prevent bad positions for users. In this report, both of these parameters were messed up. The time was set with block.timestamp instead of setting a real timestamp. This vulnerability ended up being a bad interaction with Uniswap if the transaction is left in the pool for a super long time.
Analysis Summary
# Vulnerability: Missing Expiration Deadline and Slippage Control in Ajna Pool Transactions
## CVE Details
- **CVE ID:** N/A (Internal Audit Identifier: Sherlock-Ajna-2023-01-39)
- **CVSS Score:** High (Severity label assigned by Sherlock Audit)
- **CWE:** CWE-670: Always-Incorrect Control Flow Implementation (Missing validation of transaction timeliness and output minimums)
## Affected Systems
- **Products:** Ajna Protocol
- **Versions:** 2023-01 Audit Snapshot
- **Configurations:** Interactions involving `deposit`, `withdraw`, `removeQuoteToken`, and `trade` functions within the `Pool.sol` contract.
## Vulnerability Description
The protocol lacks two critical safety mechanisms for decentralized exchange and liquidity operations:
1. **Missing Expiration Deadline:** The contracts do not enforce a `deadline` parameter. Without this, a transaction submitted during high network congestion can remain in the mempool indefinitely. If the market moves unfavorably before a validator includes the transaction, the user may execute a trade at a "stale" and disadvantageous price.
2. **Missing Slippage Control:** Functions such as `removeQuoteToken` do not allow users to specify a minimum output amount (`minReceived`). Instead, they rely on a `maxAmount` intended for removal. In volatile conditions or if front-run by a validator/searcher, the actual amount returned to the user could be significantly lower than expected, as the contract lacks a check to revert if the price impact is too high.
## Exploitation
- **Status:** PoC available (Manual Review/Theoretical exploitation)
- **Complexity:** Medium
- **Attack Vector:** Network (Mempool manipulation/Front-running/MEV)
## Impact
- **Confidentiality:** None
- **Integrity:** High (Transactions execute at prices contrary to user intent)
- **Availability:** Low (Transactions can be held until they are only profitable for the validator)
## Remediation
### Patches
- The Ajna protocol team has acknowledged the issue and applied fixes to include `deadline` checks and `minAmount` (slippage) parameters in updated versions of the pool logic.
### Workarounds
- Users should manually adjust gas fees to ensure immediate inclusion or avoid trading during periods of extreme volatility until the patched contracts are deployed.
## Detection
- **Indicators of Compromise:** Large discrepancies between the expected output and actual output of `removeQuoteToken` or `trade` events.
- **Detection Methods:** Audit smart contracts for the usage of `block.timestamp` as a deadline parameter (which is a known "noop" and effectively bypasses the check) or the total absence of `deadline` and `amountOutMin` parameters in external-facing functions.
## References
- Sherlock Audit Report: hxxps://github[.]com/sherlock-audit/2023-01-ajna-judging/issues/39
- Uniswap V2 Reference for Best Practices: hxxps://github[.]com/Uniswap/v2-periphery/blob/0335e8f7e1bd1e8d8329fd300aea2ef2f36dd19f/contracts/UniswapV2Router02[.]sol#L61