A malicious user can front run the approval mechanism, The vulnerability allows a malicious actor (User B) to exploit the approval mechanism by front-running transactions intended to change the allowance. This enables User B to maximize their allowance usage or manipulate the approval before the new changes take effect, potentially leading to unauthorized pod transfers and financial loss for the user.
The root cause of this vulnerability lies in the transaction prioritization mechanism of the Ethereum network. When User A attempts to change the approval amount, User B can observe this pending transaction and submit their own transaction with a higher gas fee, ensuring it gets mined first. This allows User B to execute transactions that utilize the current approval limit before User A's changes take effect, resulting in a front-running attack.
Scenario
1: User A approves User B to transfer 100 pods.
2: User A submits a transaction to decrease the approval amount to 50 pods.
3: User B observes this pending transaction and submits a transaction with higher gas fees to transfer 100 pods before User A’s transaction is mined.
4: User B’s transaction is mined first, utilizing the full 100 pods allowance.
1: User B can transfer the maximum allowed pods before User A's transaction to decrease the allowance is mined
2: User B can increase their allowance or transfer more pods than intended by User A, exploiting the timing of the transaction mining process.
Manual review
1: Implementing a time-lock mechanism for approval changes can provide users with a buffer period to react to any front-running attempts.
2: Make the Approval and transfer operation atomic
Invalid as per docs https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.