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

Token is refunded wrongly in the two-step swap #12

Closed
howlbot-integration bot opened this issue Nov 4, 2024 · 3 comments
Closed

Token is refunded wrongly in the two-step swap #12

howlbot-integration bot opened this issue Nov 4, 2024 · 3 comments
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-7 🤖_02_group AI based duplicate group recommendation sufficient quality report This report is of sufficient quality unsatisfactory does not satisfy C4 submission criteria; not eligible for awards upgraded by judge Original issue severity upgraded from QA/Gas by judge

Comments

@howlbot-integration
Copy link

Lines of code

https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L290-L297

Vulnerability details

Proof of Concept

The swap_2_internal_erc20 function in the Seawater AMM refunds excess tokens are refunded in the wrong token type. The happens when the original amount provided by the user is greater than the amount actually used by the AMM.

The problem here is that the function is attempting to refund the excess amount using the wrong token. When refunding excess tokens, it's using the destination token (to) instead of the source token (from). This is incorrect because the user provided original_amount of the source token (from), the AMM used amount_in of that token for the swap. Also, if there's a difference, the excess should be refunded in the original source token (from), not the destination token (to).

Bug location:

https://github.com/code-423n4/2024-10-superposition/blob/7ad51104a8514d46e5c3d756264564426f2927fe/pkg/seawater/src/lib.rs#L290-L297

if original_amount > amount_in {
    erc20::transfer_to_sender(
        to,  // Critical bug: Using destination token for refund
        original_amount
            .checked_sub(amount_in)
            .ok_or(Error::TransferToSenderSub)?,
    )?;
}

The function flows thus:

  • User provides original_amount of token from
  • AMM uses amount_in for the swap
  • If original_amount > amount_in, excess should be refunded

Refund is executed using destination token (to) instead of source token (from)

Consider a scenario given:

  • User wants to swap TokenA for TokenB
  • User approves 100 TokenA
  • AMM only requires 80 TokenA
    Expected:
  • Refund should be 20 TokenA
    Actual (buggy):
  • Protocol attempts to refund 20 TokenB

As a result, users receive refunds in wrong token type

Recommendation:

if original_amount > amount_in {
    erc20::transfer_to_sender(
-         to,
+        from,
        original_amount
            .checked_sub(amount_in)
            .ok_or(Error::TransferToSenderSub)?,
    )?;
}
@howlbot-integration howlbot-integration bot added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value 🤖_02_group AI based duplicate group recommendation bug Something isn't working duplicate-7 sufficient quality report This report is of sufficient quality labels Nov 4, 2024
howlbot-integration bot added a commit that referenced this issue Nov 4, 2024
@c4-judge c4-judge added 3 (High Risk) Assets can be stolen/lost/compromised directly upgraded by judge Original issue severity upgraded from QA/Gas by judge and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Nov 13, 2024
@c4-judge
Copy link

alex-ppg changed the severity to 3 (High Risk)

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Nov 13, 2024
@c4-judge
Copy link

alex-ppg marked the issue as satisfactory

@c4-judge c4-judge added unsatisfactory does not satisfy C4 submission criteria; not eligible for awards and removed satisfactory satisfies C4 submission criteria; eligible for awards labels Nov 20, 2024
@c4-judge
Copy link

alex-ppg marked the issue as unsatisfactory:
Invalid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working duplicate-7 🤖_02_group AI based duplicate group recommendation sufficient quality report This report is of sufficient quality unsatisfactory does not satisfy C4 submission criteria; not eligible for awards upgraded by judge Original issue severity upgraded from QA/Gas by judge
Projects
None yet
Development

No branches or pull requests

1 participant