The _approveCollateralTokenForAave
function in AaveDIVAWrapperCore
introduces a potential front-running vulnerability by failing to reset allowances to zero before increasing them. This exposes users and the protocol to race conditions where attackers can exploit existing allowances during the approval process, especially for tokens requiring zero-reset on updates (e.g., USDT). This oversight can lead to unauthorized token transfers and financial losses.
The vulnerability arises from how _approveCollateralTokenForAave
updates token allowances using safeIncreaseAllowance
without first resetting the allowance to zero. This approach does not comply with ERC20 best practices and creates opportunities for front-running attacks.
Relevant Code:
This implementation allows attackers to utilize the current allowance during the pending transaction to exploit the newly set allowance.
**Obj->**Exploit the race condition in the allowance update process to execute unauthorized token transfers.
Step-by-Step
Approval Attempt:
The protocol owner calls _approveCollateralTokenForAave
to update the token allowance for the Aave V3 Pool.
Front-Running Opportunity:
An attacker monitors the blockchain for pending transactions that invoke _approveCollateralTokenForAave
.
Exploitation:
Before the approval transaction is mined, the attacker submits a transaction to spend the current allowance.
Post-Approval Exploit:
Once the original transaction is mined, the allowance is updated to a new maximum value, enabling the attacker to spend both the remaining allowance and the newly approved allowance.
Consequences:
Unauthorized Token Transfers:
Attackers can drain tokens from the protocol or user wallets by exploiting the allowance race condition.
Financial Losses:
Users and the protocol may incur significant financial losses due to unauthorized token expenditures.
Eroded Trust:
Security flaws in the allowance mechanism can undermine user confidence in the protocol's reliability.
The following contract demonstrates how an attacker can exploit the front-running vulnerability:
Proposed Solution
Modify _approveCollateralTokenForAave
to reset the allowance to zero before updating it:
Benefit:
Prevents exploitation in tokens requiring zero-reset on allowance updates (e.g., USDT).
Adopt the permit
function to enable off-chain approval through signatures, eliminating on-chain approval transactions.
Benefit:
Reduces the risk of front-running by eliminating on-chain approval transactions.
Ensure that only tokens adhering to strict ERC20 behavior are allowed:
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.