Fit Cyan Kookaburra - Lack of validation checks will cause transaction reverts for users

[sherlock-admin4]

Fit Cyan Kookaburra

Low/Info

Lack of validation checks will cause transaction reverts for users

Summary

In multiple contracts (TaxCalculator.sol, LinearRangeCurve.sol, BaseImplementation.sol, CollectionShutdown.sol, Listings.sol), lack of checks before division operations will cause transaction reverts for users as division by zero errors occur when denominators are zero.

Root Cause

Divisions are performed without ensuring that denominators are non-zero:

• TaxCalculator.sol:

  • Line 69: Division by 1 ether - UTILIZATION_KINK without checking if the result is zero.

  interestRate_ = (((_utilizationRate - UTILIZATION_KINK) * (100 - 8)) / (1 ether - UTILIZATION_KINK) + 8) * 100;

  • Line 117: Division by _initialCheckpoint.compoundedFactor without verifying it's non-zero.

  uint compoundedFactor = _currentCheckpoint.compoundedFactor * 1e18 / _initialCheckpoint.compoundedFactor;

• LinearRangeCurve.sol:

  • Line 60: Division by end - start without ensuring end is greater than start.

  inputValue = numItems * (spotPrice * (end - block.timestamp) / (end - start));

• BaseImplementation.sol:

  • Line 199: Division by ONE_HUNDRED_PERCENT without confirming it's non-zero.

  beneficiaryFee_ = _amount * beneficiaryRoyalty / ONE_HUNDRED_PERCENT;

• CollectionShutdown.sol:

  • Lines 150, 245, 310, 343: Divisions involving ONE_HUNDRED_PERCENT without checks for zero denominators.

  // Line 150
  params.quorumVotes = uint88(totalSupply * SHUTDOWN_QUORUM_PERCENT / ONE_HUNDRED_PERCENT);
  
  // Line 245
  uint newQuorum = params.collectionToken.totalSupply() * SHUTDOWN_QUORUM_PERCENT / ONE_HUNDRED_PERCENT;
  
  // Line 310
  uint amount = params.availableClaim * claimableVotes / (params.quorumVotes * ONE_HUNDRED_PERCENT / SHUTDOWN_QUORUM_PERCENT);
  
  // Line 343
  uint amount = params.availableClaim * userVotes / (params.quorumVotes * ONE_HUNDRED_PERCENT / SHUTDOWN_QUORUM_PERCENT);

• Listings.sol:

  • Line 933: Division by _listing.duration without verifying it's non-zero.

  refund_ = (_listing.duration - (block.timestamp - _listing.created)) * taxPaid / _listing.duration;

Internal pre-conditions

1. TaxCalculator.sol

   • Line 69:
     • UTILIZATION_KINK equals 1 ether, making 1 ether - UTILIZATION_KINK zero.
   • Line 117:
     • _initialCheckpoint.compoundedFactor is zero.

2. LinearRangeCurve.sol

   • Line 60:
     • end equals start, so end - start is zero.

3. BaseImplementation.sol

   • Line 199:
     • ONE_HUNDRED_PERCENT is zero.

4. CollectionShutdown.sol

   • Lines 150, 245, 310, 343:
     • ONE_HUNDRED_PERCENT is zero.
     • Other variables in denominators are zero.

5. Listings.sol

   • Line 933:
     • _listing.duration is zero.

External pre-conditions

N/A.

Attack Path

1. Users or contracts invoke functions that perform divisions without checking denominators:

   • For example, a user calls a function that calculates interest or fees.

2. A division by zero occurs due to zero denominators:

   • The calculation attempts to divide by zero, causing an exception.

3. Transactions revert, leading to denial of service:

   • The function execution halts, and the user's transaction fails.

Impact

The affected parties cannot execute transactions involving these calculations, resulting in:

• Denial of Service:

  • Users are unable to perform essential operations, such as calculating interest, buying items, or participating in governance.

• Contract Functionality Halted:

  • Critical contract functions cannot proceed, affecting the overall system stability.

PoC

Example for LinearRangeCurve.sol Line 60:

// Scenario where end equals start
uint128 spotPrice = 1 ether;
uint128 delta = packDelta(1000, 1000); // start = end = 1000
uint256 numItems = 1;

// Unpack delta to get start and end
(uint32 start, uint32 end) = unpackDelta(delta);

// This will cause a division by zero
uint256 inputValue = numItems * (spotPrice * (end - block.timestamp) / (end - start));
// Since end == start, (end - start) == 0, causing division by zero

Similar PoCs for other instances:

• TaxCalculator.sol Line 117:

  uint256 _initialCheckpoint.compoundedFactor = 0; // Denominator is zero
  uint256 compoundedFactor = _currentCheckpoint.compoundedFactor * 1e18 / _initialCheckpoint.compoundedFactor;
  // Division by zero occurs here

• BaseImplementation.sol Line 199:

  uint256 ONE_HUNDRED_PERCENT = 0;
  uint256 beneficiaryFee_ = _amount * beneficiaryRoyalty / ONE_HUNDRED_PERCENT;
  // Division by zero occurs here

Mitigation

• Add Checks Before Division Operations:

  • Ensure denominators are not zero before performing divisions.

  require(denominator != 0, "Denominator cannot be zero");

• Specific Mitigations:

  • TaxCalculator.sol Line 69:

  uint256 denominator = 1 ether - UTILIZATION_KINK;
  require(denominator != 0, "Invalid UTILIZATION_KINK value");
  interestRate_ = (((_utilizationRate - UTILIZATION_KINK) * (100 - 8)) / denominator + 8) * 100;

  • LinearRangeCurve.sol Line 60:

  require(end > start, "End time must be greater than start time");
  inputValue = numItems * (spotPrice * (end - block.timestamp) / (end - start));

  • BaseImplementation.sol Line 199:

  require(ONE_HUNDRED_PERCENT != 0, "ONE_HUNDRED_PERCENT cannot be zero");
  beneficiaryFee_ = _amount * beneficiaryRoyalty / ONE_HUNDRED_PERCENT;

  • Listings.sol Line 933:

  require(_listing.duration != 0, "Listing duration cannot be zero");
  refund_ = (_listing.duration - (block.timestamp - _listing.created)) * taxPaid / _listing.duration;

• Initialize Constants Properly:

  • Ensure that constants like ONE_HUNDRED_PERCENT are set correctly and cannot be zero.

• Validate Input Parameters:

  • Check that all input parameters and state variables used as denominators are valid and non-zero.

---