Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In strategistBootyClaim() of BathPair there is no check that asset!=quote and strategist can claim one asset rewards two times #238

Closed
code423n4 opened this issue May 28, 2022 · 3 comments
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate This issue or pull request already exists sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2022-05-rubicon/blob/8c312a63a91193c6a192a9aab44ff980fbfd7741/contracts/rubiconPools/BathPair.sol#L588-L625

Vulnerability details

Impact

function strategistBootyClaim() is calculating and transferring strategist prize, but strategist can send asset=quote and claim one token prize two times as in code it gets strategist2Fills of asset and quote in the beginning of function.

Proof of Concept

This is strategistBootyClaim() code:

function strategistBootyClaim(address asset, address quote)
        external
        onlyApprovedStrategist(msg.sender)
    {
        uint256 fillCountA = strategist2Fills[msg.sender][asset];
        uint256 fillCountQ = strategist2Fills[msg.sender][quote];
        if (fillCountA > 0) {
            uint256 booty = (
                fillCountA.mul(IERC20(asset).balanceOf(address(this)))
            ).div(totalFillsPerAsset[asset]);
            IERC20(asset).transfer(msg.sender, booty);
            emit LogStrategistRewardClaim(
                msg.sender,
                asset,
                booty,
                block.timestamp
            );
            totalFillsPerAsset[asset] -= fillCountA;
            strategist2Fills[msg.sender][asset] -= fillCountA;
        }
        if (fillCountQ > 0) {
            uint256 booty = (
                fillCountQ.mul(IERC20(quote).balanceOf(address(this)))
            ).div(totalFillsPerAsset[quote]);
            IERC20(quote).transfer(msg.sender, booty);
            emit LogStrategistRewardClaim(
                msg.sender,
                quote,
                booty,
                block.timestamp
            );
            totalFillsPerAsset[quote] -= fillCountQ;
            strategist2Fills[msg.sender][quote] -= fillCountQ;
        }
    }

As you can see it first save the values of strategist2Fills[msg.sender][asset] and strategist2Fills[msg.sender][quote] and then calculated asset and quote prize for strategist and in the process set the values of strategist2Fills[msg.sender][asset] and strategist2Fills[msg.sender][quote]. if strategist send asset=quote then code will reward strategist for that token two times because uint256 fillCountQ = strategist2Fills[msg.sender][quote]; is before calculating and updating states for asset.
Of course because of strategist2Fills[msg.sender][quote] -= fillCountQ; it may end with underflow error if contract uses SafeMath correctly but the logic is wrong. the line uint256 fillCountQ = strategist2Fills[msg.sender][quote]; should be moved after the first if.

Tools Used

VIM

Recommended Mitigation Steps

change the logic to:

    function strategistBootyClaim(address asset, address quote)
        external
        onlyApprovedStrategist(msg.sender)
    {
        uint256 fillCountA = strategist2Fills[msg.sender][asset];
        if (fillCountA > 0) {
            uint256 booty = (
                fillCountA.mul(IERC20(asset).balanceOf(address(this)))
            ).div(totalFillsPerAsset[asset]);
            IERC20(asset).transfer(msg.sender, booty);
            emit LogStrategistRewardClaim(
                msg.sender,
                asset,
                booty,
                block.timestamp
            );
            totalFillsPerAsset[asset] -= fillCountA;
            strategist2Fills[msg.sender][asset] -= fillCountA;
        }

        uint256 fillCountQ = strategist2Fills[msg.sender][quote];
        if (fillCountQ > 0) {
            uint256 booty = (
                fillCountQ.mul(IERC20(quote).balanceOf(address(this)))
            ).div(totalFillsPerAsset[quote]);
            IERC20(quote).transfer(msg.sender, booty);
            emit LogStrategistRewardClaim(
                msg.sender,
                quote,
                booty,
                block.timestamp
            );
            totalFillsPerAsset[quote] -= fillCountQ;
            strategist2Fills[msg.sender][quote] -= fillCountQ;
        }
    }
@code423n4 code423n4 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels May 28, 2022
code423n4 added a commit that referenced this issue May 28, 2022
@bghughes bghughes added the sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity") label Jun 3, 2022
@KenzoAgada
Copy link

Note that in mitigation, the lines of:

            totalFillsPerAsset[asset] -= fillCountA;
            strategist2Fills[msg.sender][asset] -= fillCountA;

Can be changed to use SafeMath to consistently prevent underflows.
Same for quote token.

@HickupHH3
Copy link
Collaborator

Duplicate of #157

@HickupHH3 HickupHH3 marked this as a duplicate of #157 Jun 17, 2022
@HickupHH3
Copy link
Collaborator

Centralisation risk issue: #344

@HickupHH3 HickupHH3 added the duplicate This issue or pull request already exists label Jun 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working duplicate This issue or pull request already exists sponsor confirmed Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Projects
None yet
Development

No branches or pull requests

4 participants