Solodit Checklist Explained (2) : Denial-of-Service Attacks Part 2
Attacker's Mindset / Denial-of-Service Attack
Welcome back to the "Solodit Checklist Explained" series. We're continuing our exploration of the Solodit smart contract audit checklist, focusing on practical strategies for writing secure and resilient smart contracts.
This checklist serves as a vital resource for identifying potential vulnerabilities and implementing proactive security measures.
In our previous installment, "Solodit Checklist Explained (1)", we studied three checklist items (hints: withdrawal pattern, minimum transaction amount, and blacklisting) related to Denial-of-Service (DoS) attacks and provided actionable solutions for developers. If you haven't already, I recommend reviewing that article before proceeding.
In this post, we'll address three additional items from the checklist, again focusing on DoS attacks. We'll delve into queue processing vulnerabilities, the challenges presented by low-decimal tokens, and the importance of handling external contract calls safely. Let's begin.
Today's Focus: A Brief Overview
Here's what we'll cover today:
SOL-AM-DOSA-4: Blocking Queue Processing: This problem occurs when an attacker manipulates a queue to halt or disrupt its operation, leading to a denial-of-service. We'll examine how attackers can compromise processing queues.
SOL-AM-DOSA-5: Low Decimal Tokens: This problem arises when dealing with tokens with a low number of decimals. Calculations, particularly divisions, can be truncated down to zero, leading to unexpected and detrimental behavior. Such low-precision tokens can lead to integer division issues that disrupt key functions.
SOL-AM-DOSA-6: Unsafe External Calls: We'll investigate how reliance on external contracts without proper error handling can create vulnerabilities. The problem occurs when the failure of an external call isn't managed correctly, potentially causing the entire contract to revert.
These are not merely theoretical concerns. Real-world exploits have demonstrated the potential damage these vulnerabilities can inflict. Projects have suffered substantial losses due to seemingly minor oversights.
The Solodit checklist is based on a wealth of audit findings, bug bounty reports, and real-world incidents. By addressing these checklist items, you can learn from past mistakes and improve the security of your code.
Now, let's examine each checklist item in detail, using illustrative code examples. These examples are simplified to highlight the core vulnerabilities.
SOL-AM-DOSA-4: Can an attacker block or prevent queue processing to cause service disruption?
The Problem: If your smart contract relies on queues for task processing, an attacker might manipulate a specific status within the queue to prevent correct processing.
The Checklist Question: "Can an attacker block or prevent queue processing to cause service disruption?"
The Fix: Your queue processing mechanism requires robust error handling and fallback mechanisms to ensure process continuation even when issues arise.
Example:
Consider a withdrawal queue example:
Users request withdrawals and some flags are set to indicate the request active.
Attackers can exploit
resetUserStatus
after their withdrawal is enqueued and DOS other users from doing the same.
To exploit this, an attacker can do the following:
Request for withdrawal.
Call the
resetUserStatus
function.The
processNextWithdrawal
function will revert, causing an ongoing DOS attack.
Remediation:
The following mitigations can be implemented:
Restrict modifying
withdrawalRequested
status to the admin.Ensuring validation checks to avoid zero-value transactions.
Implementing a fallback function to handle unexpected errors.
SOL-AM-DOSA-5: Can low decimal tokens cause DoS?
The Problem: Tokens with a low number of decimals can lead to issues with integer division, resulting in rounding down to zero.
Imagine a token streaming contract that distributes tokens over a period. If tokensPerSecond
rounds to zero due to integer division with low-decimal tokens, the distribution function will be blocked.
The Checklist Question: "Can low decimal tokens cause DOS?"
The Fix: Implement logic to handle low decimals that prevents breaking the transaction process due to rounding errors.
Example:
Consider a TokenStream
contract that streams a certain amount of tokens to users, where:
total_tokens
need to be transferred to the contracttoken_per_second
can be rounded to zero, since we are using a token with 1 decimal.distributeTokens
function will revert.
Remediation:
Ensure that the contract handles low decimal tokens correctly by scaling math formulas to mitigate integer rounding during calculations.
SOL-AM-DOSA-6: Does the protocol handle external contract interactions safely?
The Problem: Many smart contracts rely on external contracts for interactions. Unexpected behaviors from external contracts can cause the whole system to revert. Failing to appropriately handle these external errors leads to a Denial-of-Service (DOS) vulnerability.
The Checklist Question: "Does the protocol handle external contract interactions safely?"
The Fix: Ensure that there is robust error handling for external contract interactions to protect protocol integrity regardless of external contract performance.
Example:
Consider a contract that interacts with an external Chainlink price feed. Without proper error handling using try/catch, any revert from the external feed will cascade upward, and the contract will revert.
The
getPrice
function retrieves the price feed dataWhen the external chainlink Oracle fails, the entire code reverts
The
calculateSomethingImportant
function depends ongetPrice
and will also revert.
Remediation:
Wrap external contract calls in try/catch
blocks to handle reverted errors and implement a fallback or cached value.
NOTE: There is an edge case where the external contract spends gas intentionally that can make the catch block fail too! We will discuss this later.
Conclusion
We've explored three critical checklist items designed to strengthen your smart contracts against DoS attacks: queue processing vulnerabilities, the challenges associated with low decimal tokens, and the importance of handling external contract interactions safely.
Remember, the provided examples are intended to illustrate core vulnerabilities. It is essential to understand the underlying principles and adapt these concepts to your specific use cases.
All the examples are available on GitHub solodit-checklist-blog-examples!
By implementing these recommendations, you can significantly improve the security and resilience of your smart contracts.
Stay tuned for the next installment of the "Solodit Checklist Explained" series.
Keep ‘em coming. Amazing writeup,btw🤝