058.md

Decent Smoke Owl

High

Incorrect safeTransferFrom parameter when creating stop limit orders

H-07: Incorrect transferFrom/safeTransferFrom parameter when creating stop limit/oracleless orders

Summary

createOrder() function in StopLimit and OracleLess contracts incorrectly transfer funds from user provided recipient. Since the protocol relies on previous approvals from users, it is possible to create orders against the will of the recipient who has approved funds to create an order.

Root Cause

Instead of transferring the funds from msg.sender, funds are incorrectly transferred from msg.sender. tokenIn.safeTransferFrom(recipient, address(this), amountIn)

procureTokens(tokenIn, amountIn, recipient, permit, permitPayload)

createOrder(): https://github.com/sherlock-audit/2024-11-oku/blob/ee3f781a73d65e33fb452c9a44eb1337c5cfdbd6/oku-custom-order-types/contracts/automatedTrigger/StopLimit.sol#L146C1-L189C1

procureTokens(): https://github.com/sherlock-audit/2024-11-oku/blob/ee3f781a73d65e33fb452c9a44eb1337c5cfdbd6/oku-custom-order-types/contracts/automatedTrigger/OracleLess.sol#L49

Internal pre-conditions

N/A

External pre-conditions

N/A

Attack Path

Consider the following scenario:

User A approve StopLimit to spend his funds in order to create an order. There will be a short period between the approval and the creation of order. During this period, attacker can call createOrder() with recepient parameter equal to user A address. Since user A has previously approved the funds, everyone can create an order from his name. New order can be completely different - other tokenOut, worse slippage parameters. And since everyone can trigger performUpkeep() before user try to modify the malicious order, user will get completely different outcome than his initial desire.

Impact

Overall, the impact is unexpected behavior for users. Loss of funds can occur, if there is a high slippage parameter provided by the attacker.

PoC

No response

Mitigation

Consider taking the funds from msg.sender.