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

Sneaky Eggplant Fly - Insecure calls to safeTransferFrom leads to users tokens steal by attacker #789

Open
sherlock-admin2 opened this issue Dec 9, 2024 · 1 comment
Labels
Sponsor Confirmed The sponsor acknowledged this issue is valid Will Fix The sponsor confirmed this issue will be fixed

Comments

@sherlock-admin2
Copy link

Sneaky Eggplant Fly

Medium

Insecure calls to safeTransferFrom leads to users tokens steal by attacker

Summary

The function safeTransferFrom() is used to transfer tokens from user to the protocol contract. This function is used in modifyOrder and createOrder with the recipent address as the owner form who the tokens will be transfered from. An attacker can abuse this functionnality to create unfaire orders for a protocol user that approve more tokens than needed to the protocol contract the fill the order immediatly and gain instant profit while the victim lost his tokens.

Root Cause

In OracleLess.sol::procureTokens():280
https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/OracleLess.sol#L280
procureTokens() implement tokens transfer from an owner address to the protocol contract

In StopLimit.sol::createOrder():171
https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/StopLimit.sol#L171

In StopLimit.sol::modifyOrder():226-230
https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/StopLimit.sol#L226-L230

In Bracket.sol::modifyOrder():250-254
https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L250-L254

Internal pre-conditions

No response

External pre-conditions

  1. A user should have approve more tokens than needed for a trade that whould result in some residual allowance to the protocole contract

Attack Path

  1. The attacker create/modify an unfaire order with the victim as recipent with an amounIn <= residual allowance
  2. The prococol then transfer the tokens from the user to create the order
  3. The attacker fill the order an gain instant profit

Impact

No response

PoC

No response

Mitigation

It would be better to use msg.sender to ensure that the recipient/owner of the order is the order creator or juste use msg.sender as parameter to the safeTransferFrom() function call instead of order recipient

@sherlock-admin3 sherlock-admin3 added Sponsor Confirmed The sponsor acknowledged this issue is valid Will Fix The sponsor confirmed this issue will be fixed labels Dec 19, 2024
@sherlock-admin2
Copy link
Author

The protocol team fixed this issue in the following PRs/commits:
gfx-labs/oku-custom-order-types#1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Sponsor Confirmed The sponsor acknowledged this issue is valid Will Fix The sponsor confirmed this issue will be fixed
Projects
None yet
Development

No branches or pull requests

2 participants