After having audited quite a few orderbook implementations, I've compiled a list of common vulnerabilities that auditors should be vigilant of. I hope this can provide you with insights for your next audit of such an implementation.
These issues are not solely for general orderbooks (User A creates an order and User B accepts it) but also for general orderbook implementations where the price is already matched and work on a FiFo base.
1. Denial of Service (DoS):
Orderbooks are inherently susceptible to DoS attacks through various scenarios that disrupt their normal flow. Here are a few examples:
Multi-Offer Creations with 1 Wei: Attackers can spam the orderbook with offers that are economically insignificant but can clog the system, preventing genuine transactions from being processed. (For FiFo implementations)
Revert Upon ETH Receipt: If an orderbook implementation accepts ETH and reverts transactions upon receiving ETH for certain orders, the order creator may DoS the orderbook (For FiFo implementations)
Blacklisting Scenario for Recipients: In cases where a recipient is blacklisted from receiving certain tokens (like USDT), the orderbook can be manipulated to reject transactions, causing a disruption in service. (For FiFo implementations)
Malformed Tokens: Utilizing tokens that revert on transfer attempts (for specific callers) can cause transactions to fail, leading to a denial of service. (For FiFo implementations)
For general orderbooks (User A creates an order and User B accepts it), the DoS potential is rather low as each “broken order” would not pose a risk to the system.
2. Frontrunning of Order Acceptance:
Frontrunning poses a significant threat to the integrity of orderbook systems, enabling attackers to manipulate orders to their advantage:
Increase Price: By changing an order and increasing the price just before it's accepted, an attacker can drain the entire approved amount from a victim. This is an issue which was almost present in all orderbook implementations I have audited.
Cancel and Replace: If the system allows, an attacker could cancel an existing order and replace it with their a new using the same ID, exploiting the orderbook's logic (if it is vulnerable to this).
3. Index Correctness for Order Creations
Ensuring the correctness of index handling is crucial for the integrity of order creations. Flawed indexing can lead to overwrites, lost orders, or duplicate entries, compromising the system's reliability.
4. Cancellation Logic
Order cancellation mechanisms must be secure and robust. Incorrect handling can lead to situations where orders are either not properly cancelled, allowing them to be filled subsequently, or improperly releasing locked funds.
5. Reentrancy Risks
Reentrancy vulnerabilities are almost always existent, specifically for orderbook contracts that perform external calls could be vulnerable to reentrancy, or if they transfer tokens within callbacks or native ETH.
6. Sophisticated: Order to self
An attacker placing orders to themselves can exploit potential flaws in the system's logic, leading to unexpected behavior such as draining funds or locking up the orderbook. This would be a more creative exploit idea.
These issues are not solely for general orderbooks (User A creates an order and User B accepts it) but also for general orderbook implementations where the price is already matched and work on a FiFo base.
1. Denial of Service (DoS):
Orderbooks are inherently susceptible to DoS attacks through various scenarios that disrupt their normal flow. Here are a few examples:
Multi-Offer Creations with 1 Wei: Attackers can spam the orderbook with offers that are economically insignificant but can clog the system, preventing genuine transactions from being processed. (For FiFo implementations)
Revert Upon ETH Receipt: If an orderbook implementation accepts ETH and reverts transactions upon receiving ETH for certain orders, the order creator may DoS the orderbook (For FiFo implementations)
Blacklisting Scenario for Recipients: In cases where a recipient is blacklisted from receiving certain tokens (like USDT), the orderbook can be manipulated to reject transactions, causing a disruption in service. (For FiFo implementations)
Malformed Tokens: Utilizing tokens that revert on transfer attempts (for specific callers) can cause transactions to fail, leading to a denial of service. (For FiFo implementations)
For general orderbooks (User A creates an order and User B accepts it), the DoS potential is rather low as each “broken order” would not pose a risk to the system.
2. Frontrunning of Order Acceptance:
Frontrunning poses a significant threat to the integrity of orderbook systems, enabling attackers to manipulate orders to their advantage:
Increase Price: By changing an order and increasing the price just before it's accepted, an attacker can drain the entire approved amount from a victim. This is an issue which was almost present in all orderbook implementations I have audited.
Cancel and Replace: If the system allows, an attacker could cancel an existing order and replace it with their a new using the same ID, exploiting the orderbook's logic (if it is vulnerable to this).
3. Index Correctness for Order Creations
Ensuring the correctness of index handling is crucial for the integrity of order creations. Flawed indexing can lead to overwrites, lost orders, or duplicate entries, compromising the system's reliability.
4. Cancellation Logic
Order cancellation mechanisms must be secure and robust. Incorrect handling can lead to situations where orders are either not properly cancelled, allowing them to be filled subsequently, or improperly releasing locked funds.
5. Reentrancy Risks
Reentrancy vulnerabilities are almost always existent, specifically for orderbook contracts that perform external calls could be vulnerable to reentrancy, or if they transfer tokens within callbacks or native ETH.
6. Sophisticated: Order to self
An attacker placing orders to themselves can exploit potential flaws in the system's logic, leading to unexpected behavior such as draining funds or locking up the orderbook. This would be a more creative exploit idea.
