search

hats-finance / Possum-Labs--Portals--0xed8965d49b8aeca763447d56e6da7f4e0506b2d3

GNU General Public License v2.0
0 stars 2 forks source link

Frontrunning Vulnerability in updateMaxLockDuration Function #9

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

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

Github username: @0xmahdirostami Twitter username: 0xmahdirostami Submission hash (on-chain): 0xe44f2771588a80530cab75c4bcfcf85bed322bc88e642fb09b58a5855b6ab60e Severity: high

Description: Description\

In the _updateAccount function, the calculation for portalEnergyIncrease is based on the difference between maxLockDuration and accounts[_user].lastMaxLockDuration.

        /// @dev Calculate the increase of portalEnergy due to balance increase
        uint256 portalEnergyIncrease = (accounts[_user].stakedBalance * (maxLockDuration - 
            accounts[_user].lastMaxLockDuration) + (_amount * maxLockDuration)) / SECONDS_PER_YEAR;

a potential frontrunning vulnerability where an attacker could watch the mem pool and front-run updateMaxLockDuration function and stake large amounts before this update, and unstake just after this update.

Impact\

The vulnerability allows an attacker to gain a substantial amount of portal energy within a single block duration by staking just before the maxLockDuration update and unstaking right after the update.

Attachments\

  1. Proof of Concept (PoC) File

  2. Revised Code File (Optional)

    It is recommended to modify the calculation for portalEnergyIncrease to consider both the change in maxLockDuration and the user's stake time.

PossumLabsCrypto commented 7 months ago

Invalid finding.

_updateAccount() also increases the maxStakeDebt of the user by the portalEnergyIncrease. This ensures that the "attacker" cannot withdraw his staked amount if he decides to sell this PE in the internal LP. There is no "surplus" PE gained by this frontrunning activity.