Prevent Victim User From gaining portalEnergyEarned

[hats-bug-reporter[bot]]

Github username: @0xmahdirostami Twitter username: 0xmahdirostami Submission hash (on-chain): 0x11b61e6b0f2f96d92a62b21637a4f55a22e181795e4fc231a7633caaaf901b5a Severity: medium

Description: Description\ In the _updateAccount function, the calculation of portalEnergyEarned is susceptible to manipulation by malicious users if their staked balance is less than SECONDS_PER_YEAR. By repeatedly calling burnPortalEnergyToken with a small amount(amount 1) and the victim user as _recipient, a malicious user could prevent victim users from earning portalEnergyEarned.

Impact\ While the impact is currently limited to users with low staking balances, it could have a more significant impact if the protocol decides to use low decimal tokens as principal tokens.

1. Proof of Concept (PoC) File

   for example, user A has 31535999 staked amount. maliouse user could call burnPortalEnergyToken(1, UserA) every seconds. so 31535999 * 1 / 31536000=0 and user A doesn't get any energy.

2. Revised Code File (Optional)

   It's recommended to remove the unnecessary account update in the burnPortalEnergyToken function to prevent the manipulation of portalEnergyEarned. The update seems unnecessary for the context of burning portal energy tokens, and removing it mitigates the vulnerability.

         /// @dev Require that the caller has sufficient tokens to burn
         if(portalEnergyToken.balanceOf(address(msg.sender)) < _amount) {revert InsufficientBalance();}

-        ///@dev Update the recipient´s stake data
-        _updateAccount(_recipient,0);
-
         /// @dev Increase the portalEnergy of the recipient by the amount of portalEnergyToken burned
         accounts[_recipient].portalEnergy += _amount;

[0xmahdirostami]

In the current POC, if the principal token has 6 decimals like USDT, 31,535,999 ≈ 30 Dollars(stake amount value), if has 8 decimals like WBTC, 31,535,99 ≈ 9,000 dollars(stake amount value).

In total, in the case of stake amount * time < second per year, malicious users could prevent anyone from gaining energy.

As I'm seeing now it's a direct loss of funds for the users and should be labelled as high. I leaved it to the team to recognize the severity.

[PossumLabsCrypto]

Thank you for the submission! 👍

This attack can be considered a griefing attack which is placed in the medium category.

However, the economic incentives here are so skewed that it is only of theoretical nature. This attack requires one transaction every second. If we assume Tx costs of 5 cents on Arbitrum, that´s more than 1.5M USD in transaction costs to prevent a single user to earn yield for a year. The user could still withdraw their stake though, which reduces the economic damage tremendously.

Also, HLP has 18 digits which further decreases the efficiency of this attack but even if we consider wBTC and the like, it´s not a viable activity.

I´m happy to acknowledge this as a low because it better fits the category of "contract doesn´t work as intended"

[0xmahdirostami]

Thank you for your input, @PossumLabsCrypto . I would like to add that in the case of wBTC, if the staked amount is low, an attacker could call this function every 5-10 seconds instead of every second. It’s important to note that griefing attacks could have other incentives besides economic ones. For example, preventing users from gaining energy could cause them to leave the protocol and create trust issues for protocol.

[PossumLabsCrypto]

I fully agree, it´s never good to have the potential for griefing in a protocol for many reasons.

However, there is a large difference between "possible" and "likely or practical" which makes the categorisation to low appropriate in this case.

Thanks again for lending your eagle eyes and congratulations for the valid submission! :)