024.md

Slow Tan Swallow

Medium

When users increase their vouch they will receive some part of the fees that thei've paid

Summary

Doing vouchByAddress then increaseVouch would be more beneficial for users as they would receive some part of the entry fee. Thus users can exploit this to get some part of their paid fee back and lower the fees for the rest of the users.

This happens as increaseVouch would applyFees and since our user would own some percentage of the total vouch balance, he would be entitled to that % of the fees.

https://github.com/sherlock-audit/2024-11-ethos-network-ii/blob/main/ethos/packages/contracts/contracts/EthosVouch.sol#L426

  function increaseVouch(uint256 vouchId) public payable nonReentrant {
    // ...
    (uint256 toDeposit, ) = applyFees(msg.value, true, subjectProfileId);
  }

https://github.com/sherlock-audit/2024-11-ethos-network-ii/blob/main/ethos/packages/contracts/contracts/EthosVouch.sol#L949

  function applyFees(...) internal returns (uint256 toDeposit, uint256 totalFees) {
     // ... 
      if (vouchersPoolFee > 0) {
        vouchersPoolFee = _rewardPreviousVouchers(vouchersPoolFee, subjectProfileId);
      }

https://github.com/sherlock-audit/2024-11-ethos-network-ii/blob/main/ethos/packages/contracts/contracts/EthosVouch.sol#L721-L731

   function _rewardPreviousVouchers(...) internal returns (uint256 amountDistributed) {
    // ...
    uint256 remainingRewards = amount;
    for (uint256 i = 0; i < totalVouches && remainingRewards > 0; i++) {
      Vouch storage vouch = vouches[vouchIds[i]];
      if (!vouch.archived) {
        //@autism since our user already has `vouch.balance` he would receive % of the fees he pays
        // amount * balance / totalBalance
        uint256 reward = amount.mulDiv(vouch.balance, totalBalance, Math.Rounding.Floor);
        if (reward > 0) {
          vouch.balance += reward;
          remainingRewards -= reward;
        }
      }
    }

See Attack Path for a good example

Root Cause

applyFees acting as weights, distributing to all users Users receiving rewards for their own vouching

Internal pre-conditions

No response

External pre-conditions

Users to first vouchByAddress then increaseVouch

Attack Path

Bob has 9 ETH vouched to him

Normal case

1. Alice vouches 20 ETH to Bob, where 10% of that goes to the rest of the vouchers
2. Alice has vouched 18 ETH to Bob (2 ETH paid as fee)

Attack

1. Alice vouches 10 ETH to Bob (1 ETH fee)
2. Bob has 18 ETH vouched for him (50% is from Alice - 9 ETH)
3. Alice vouches again 10 ETH to Bob (sending 1 ETH as rewards)
4. However since Alice holds 50% of his vouches (9 ETH) she claims 50% of the fees (0.5 ETH)

First scenario Alice vouched 20ETH and pays 2 ETH fees, as it should. Second scenario Alice vouched 20ETH and pays only 1.5 ETH in fees.

Note that the more the vouch increase is split between TX the more our user will save on fees.

Impact

Users can reduce the fees they pay. They also steal some fees from the rest of the vouchers

PoC

No response

Mitigation

Consider not returning any fees to msg.sender who increases it's vouch.