161.md

Ripe Gingham Hare

Medium

Division by Zero in SolidlyV2AMO.sol Leads to DoS attack

Summary

The missing zero-check on boostReserve in the _validateSwap function will cause a division by zero error for users, as an attacker can manipulate the BOOST-USD liquidity pool to set boostReserve to zero

Root Cause

In SolidlyV2AMO.sol, the _validateSwap function lacks a zero-check on boostReserve before performing division, leading to a potential division by zero error.

Internal pre-conditions

The boostReserve variable in the BOOST-USD pool is zero.

External pre-conditions

An attacker manipulates the BOOST-USD liquidity pool to reduce boostReserve to zero by swapping out all BOOST tokens.

Attack Path

1. Attacker removes all BOOST tokens from the BOOST-USD pool, reducing the "boostReserve" to zero.
2. User calls either the "mintSellFarm" or "unfarmBuyBurn" function.
3. These functions internally call "_validateSwap", which tries to calculate "(FACTOR * usdReserve) / boostReserve".
4. Since "boostReserve" is zero, this results in a division by zero error, causing the transaction to fail.
5. As a result, users are unable to perform key AMO functions, leading to a denial of service.

Impact

The users cannot execute mintSellFarm and unfarmBuyBurn functions, leading to a denial of service in maintaining the BOOST token's peg. The protocol's ability to perform AMO operations is hindered until the issue is resolved.

PoC

No response

Mitigation

Add a zero-check for boostReserve in the _validateSwap function to prevent division by zero

function _validateSwap(bool boostForUsd) internal view override { (uint256 boostReserve, uint256 usdReserve) = getReserves(); if (boostReserve == 0) revert InvalidReserveRatio({ratio: 0}); if (boostForUsd && boostReserve >= usdReserve) revert InvalidReserveRatio({ratio: (FACTOR * usdReserve) / boostReserve}); if (!boostForUsd && usdReserve >= boostReserve) revert InvalidReserveRatio({ratio: (FACTOR * usdReserve) / boostReserve}); }