hats-finance / Fenix-Finance-0x83dbe5aa378f3ce160ed084daf85f621289fb92f

0 stars 0 forks source link

Adversary can steal all bribe rewards #2

Open hats-bug-reporter[bot] opened 6 months ago

hats-bug-reporter[bot] commented 6 months ago

Github username: @deadrosesxyz Twitter username: @deadrosesxyz Submission hash (on-chain): 0x582d7050f2de893699c434f390798690c49a7e486b6c4f73d7cb4350370b2a7f Severity: high

Description: Description\ Adversary can steal all bribe rewards. I have previously reported the issue to Retro, Thena and Chronos, so description is copied

Attack Scenario\ So here's the attack path:

  1. User mints lock for dust amounts. (let's say 1 wei) One for every added gauge within the project.
  2. User votes 1 NFT to every different gauge.
  3. User creates a lock for a relatively high amount of tokens. (let's say 1000e18)
  4. A week passes. The user's balance in each gauge is now 0.
  5. User votes with the high-value NFT for the first gauge. His balance there is now equivalent to this NFT's balance (1000e18) 6.User calls vote.reset for the low-value NFT at the same (first) gauge. His balance is then equal to the high-value NFT's - low-value NFT's (1000e18 - 1 wei)
  6. User calls vote.reset on the high-value NFT. Since its value is lower than the current balance of the user, the user's balance will not be reduced. (1000e18 - 1 wei < 1000e18)
  7. Repeat steps 5-7 for all available gauges

In the end the user has not voted with any of the NFT's. Despite this, the user has a balance in all gauges. The user can then send the high-value NFT to his other wallet, where he has such low-value NFTs set from last week and repeat this attack endlessly. In the end, the user can have an arbitrary high balance in all bribes, therefore getting all of the rewards for themselves. Furthermore, since the balance will be spread out across multiple wallets and none of them will have a suspiciously high balance, this could go unnoticed for long time.

Impact Adversary can steal all rewards allocated for the upcoming week. Under some conditions and assumptions, this could potentially remain unnoticed for a prolonged time frame.

Attachments

  1. Proof of Concept (PoC) File

  2. Revised Code File (Optional)

BohdanHrytsak commented 6 months ago

Thank you for the submission.

Although this submission is not very detailed and it was really hard for me to understand what it was about, as there are confusing definitions of both gauge, bribe, balance in gauge. When testing, the example attack showed that the user removes his vote from a small NFT, after a large NFT, as a result, although the vote is removed in Voter, the user's balance in Bribe (internal/external) of a large NFT will remain

This leads to the fact that the user, without having real votes in the bribe, has fake ones that have not been deleted, which will allow him to receive a reward from the bribe, not all, but a certain significant amount https://github.com/Satsyxbt/Fenix/blob/7b81d318fd9ef6107a528b6bd49bb9383e1b52ab/contracts/bribes/BribeUpgradeable.sol#L250

Since this is a way of taking unlawful benefits from other users with a path without additional conditions - high

This code comes from the OOS section, but because of the criticality in the scope