Skip to content

Latest commit

 

History

History
52 lines (45 loc) · 2.79 KB

057.md

File metadata and controls

52 lines (45 loc) · 2.79 KB

Powerful Honeysuckle Anteater

High

Hardcoding the deposit amount to 1000 for rewards calculation which makes it vulnerable to sybil attacks.

Summary

Hardcoding the deposit amount in the calculation of the cumulativeValue in CDSLib.sol to 1000 would give an unfair advantage to someone who deposits less while receiving the same amount of rewards as someone who deposits more. This also enables Sybil attacks.

Root Cause

Hardcoding the deposited amount to 1000 USD for the reward mechanism is critical, as it allows for Sybil attacks and unfair distribution of rewards.

The function calculateCumulativeValue() in CDSLib.sol is used when withdrawing and depositing in CDS, as well as in the Borrowing contract: The function calculateCumulativeValue() in CDSLib.sol is used, when withdrawing and when depositing in CDS, as well as in Borrowing contract:

    function calculateCumulativeValue(
        uint128 _price, // in wei.
        uint256 totalCdsDepositedAmount,
        uint128 lastEthPrice, // 1e2
        uint256 vaultBal // in wei.
    ) public pure returns (CDSInterface.CalculateValueResult memory) {
@>>     uint128 _amount = 1000; //@audit hardcoded value would lead to sybil attacks/unfair distribution
        uint128 priceDiff;
        uint128 value;
        bool gains;
        if (totalCdsDepositedAmount == 0) {
            value = 0;
            gains = true;
        } else {
            if (_price > lastEthPrice) {
                priceDiff = _price - lastEthPrice;
                gains = true;
            } else {
                priceDiff = lastEthPrice - _price;
                gains = false;
            }
            value = uint128((_amount * vaultBal * priceDiff * 1e6) / (PRECISION * totalCdsDepositedAmount));
        }
        return CDSInterface.CalculateValueResult(value, gains);
    }

Attack Path

  • An attacker could create multiple deposits to gain a larger share of the rewards.
  • The attacker could make minimal deposit amounts and perform as many deposits as possible.

Impact

Attackers could extract the majority of rewards, or all rewards would be distributed unfairly, as each deposit's cumulative value for reward distribution is calculated based on a fixed amount of 1000 instead of the actual deposited amount.

Mitigation

There are effective ways to track rewards for many users. Consider implementing the rewardDebt logic from MasterChef contracts.