Full Report
Denial of Service (DoS) are attacks that come from disallowing access to a service. In the context of blockchain applications, this can be completely rejects access to the service to somebody else or to yourself accidentally. Both of these are valid findings are auditors on Code4rena. The first one the author mentions is DoS by Underflow. In Solidity, there are now built in protections to prevent overflows and underflows. However, if there is a flaw in the contract, the protection could become a DoS itself. An example of the underflow DoS was a contract where there is a senior and junior vault. When a junior vault would transfer it to the senior vault, it had to convert from WETH to USDC to stake. The senior vault gains value by increasing the debt of the junior vault. There is validation to ensure that the vault is not beyond its cap, which was covered by integer overflow protection. If that is true, then it will revert on the same call for withdraw and deposit. To solve this, return 0 on the value instead of underflowing. Another common bug is DoS via gas limit. In the example, a user deposit was tracked in an array. Later on, when withdrawing USDC, it goes from an index of 0 to an infinite size. By making the array too big, users may be denied access from gas limitations. This can be solved by programming without controllable array, removing previously used values that are no longer needed or having indexed based calls in cases where the array is too long. DoS by nonReentrant modifier. An example of this starts with contract had various operations related to staking, rewards and transferring funds with nonReentrant modifiers on them. There existed a unstaking code path that hit a transfer function where BOTH had the nonReentrant modifier on it. Since this was the case, all calls to the unstake function with the case of there being vault rewards to fail. The solution the problem could be done in a few ways. In particular, having an external function with the modifier and an internal function without the modifier to access the functionality. The next item refers to external calls reverting. The example they give is a chainlink oracle may reject calls. The solution to this appears to depend on the external call being made. However, to me, having a fallback for handling an oracle is dumb... the whole point is that this is a trusted entity that is secure. Any logic against this could lead to compromise. DoS via Malicious Receiver. There is commonly logic that allows for the arbitrary callback of contracts. If this is implemented for various bits of functionality, an attacker could force a revert to happen, blocking the contract forever. In the example case, it a contract with basic loan functions liquidate() and endAuction() which call the users defined function. An attacker can revert all of these calls to make it impossible to end an auction or liquidate. Overall, interesting post on denial of service problems in Solidity.
Analysis Summary