Front-Running in buyShares Function

Summary

This report identifies a high-severity front-running vulnerability in the buyShares function of the GSPFunding contract. The issue arises due to the function's reliance on the current token balance minus the reserve to mint new shares for liquidity providers (LPs), coupled with the separate processing of transfer and buyShares functions.

Vulnerability Detail

buyShares() function calculates share amounts based on real-time token balance, which is transparent on the blockchain. Malicious actors can monitor the Ethereum mempool for transfer transactions to the contract. By detecting a pending buyShares transaction, they can execute a buyShares transaction with a higher gas fee than the lp, leading to its prioritization in the block.

Impact

This vulnerability enables attackers to mint shares unfairly, leading to potential financial losses for genuine LPs and disrupting the intended token distribution mechanics.

Code Snippet

Here is how buyShares() function calculates the input amount. https://github.com/sherlock-audit/2023-12-dodo-gsp/blob/main/dodo-gassaving-pool/contracts/GasSavingPool/impl/GSPFunding.sol#L31-L39

// The balance of baseToken and quoteToken should be the balance minus the fee
        uint256 baseBalance = _BASE_TOKEN_.balanceOf(address(this)) - _MT_FEE_BASE_;
        uint256 quoteBalance = _QUOTE_TOKEN_.balanceOf(address(this)) - _MT_FEE_QUOTE_;
        // The reserve of baseToken and quoteToken
        uint256 baseReserve = _BASE_RESERVE_;
        uint256 quoteReserve = _QUOTE_RESERVE_;

        // The amount of baseToken and quoteToken user transfer to GSP
        baseInput = baseBalance - baseReserve;
        quoteInput = quoteBalance - quoteReserve;

Tool used

Manual Review

Recommendation

It is recommended to implement a new function that combines the actions of transfer and buyShares into a single atomic operation.

Duplicate of #78

sherlock-audit / 2023-12-dodo-gsp-judging

zach030 - Front-Running in buyShares Function #158