The ParaSwapUtils library uses the safeApprove
function from OpenZeppelin to set token allowances without first resetting any existing allowance. This pattern may lead to issues if the token contract exhibits non-standard behavior or if a non-zero allowance already exists, potentially causing the approval to fail or be manipulated.
Issue:
The library directly calls:
without checking whether the allowance is already set or resetting it to zero.
Context:
Some ERC20 tokens do not behave as expected when increasing or setting allowances directly if a previous non-zero value exists. This can lead to race conditions or unexpected behavior.
Inter‑Contract Considerations:
As the library functions assume a standard ERC20 behavior, tokens with non-standard implementations could cause the approval step to fail, leaving the swap unexecutable or exposing the contract to potential manipulation.
Approval Failures:
If the allowance is not zero, the call to safeApprove may revert or leave an unexpected allowance, breaking the swap process.
Race Conditions:
An attacker might exploit timing issues around token approvals if the allowance is manipulated during the external call.
Economic Risk:
Failure to properly approve tokens could lead to stuck funds or failed swaps, impacting the protocol’s operation.
This PoC demonstrates how the absence of an allowance reset in the approval pattern can lead to issues. It simulates a scenario where a token already has a non-zero allowance, and then the swap function attempts to set a new allowance without resetting it.
Attacker/Malicious Token: A token contract that mimics non-standard behavior by rejecting approval changes when a non-zero allowance exists.
Legitimate User: The caller attempting to execute the swap.
Protocol: The ParaSwapUtils library which attempts the approval and swap.
Setup:
A NonStandardToken
is deployed that disallows changing an allowance if it is already non-zero.
Attack Execution:
The TestApprovalPattern
contract first sets a non-zero allowance manually. It then calls the swap function from the library, which attempts to approve a new allowance without resetting.
Result:
The call reverts with the error "Allowance not zero," demonstrating how the insecure approval pattern may fail with non-standard tokens.
Manual Code Review
Reset Allowance:
First set the token allowance to zero before setting it to the desired amount:
Alternative Pattern:
Consider using transferFrom mechanisms if the integration permits, which avoids approval altogether.
Token Compatibility Checks:
Where possible, ensure that the tokens interacted with conform to expected standards.
USDT or other unusual ERC20 tokens: out of scope. For the other reports: No proof that the allowance won't be consumed by the receiver.
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.