The contract does not perform adequate validation on user-provided token amounts in various functions, such as when redeeming position tokens and redeeming WTokens. The absence of checks or restrictions allows users to send unexpected or malicious token amounts, which could lead to vulnerabilities such as overflows, underflows, or loss of funds.
The following areas in the contract are affected by the lack of validation for user input related to token amounts:
**Redeem Position Tokens (_redeemPositionToken) line 253 on **AaveDIVAWrapperCore.solcontract:
The function does not check whether the token amounts are within the expected range, which can lead to users redeeming more tokens than they should. It uses the token balance of the sender without verifying if it's appropriate for the transaction.
**Redeem WTokens (_redeemWToken) line 311 **AaveDIVAWrapperCore.solcontract:
A similar lack of validation occurs when redeeming WTokens. The function doesn't confirm that the amount being redeemed is valid before proceeding with the operation.
**Claim Yield (_claimYield) on line 332 **AaveDIVAWrapperCore.solcontract:
Although this function indirectly handles amounts (via _getAccruedYieldPrivate), it doesn't properly validate or sanitize the yield amounts before making the withdrawal request to Aave, potentially leading to unexpected behavior if the yield is manipulated.
The input for token amounts is used directly without boundary checks, potentially leading to issues with large values (overflows) or unexpected behavior.
Overflows/Underflows: If large, malicious amounts are provided, this can lead to integer overflows or underflows in calculations, potentially causing unexpected behavior or loss of funds.
Loss of Funds: Allowing the redemption of more tokens than the sender owns or intends could lead to loss of funds.
Protocol Disruption: By bypassing the intended checks on the amounts, an attacker might cause unwanted withdrawals or token transfers, disrupting the proper flow of operations.
Proof of Concept (PoC) for Lack of Validation on User Input for Token Amounts
This PoC demonstrates the vulnerability of the contract when it doesn't validate the user input for token amounts. It allows an attacker to redeem an unexpectedly large amount of tokens without checks, potentially causing undesired behavior.
Attacker: An external user who interacts with the contract to redeem an excessive number of tokens.
Victim: The contract or the protocol, which might be drained of tokens or face unexpected behavior due to unvalidated input.
Protocol: The smart contract system (AaveDIVAWrapper) that handles the redemption of tokens.
Line-by-line comments:
- Line 1-10: Set up the attacker contract, which targets the AaveDIVAWrapper contract
- Line 17: Call the _redeemPositionToken function with a maliciously large amount (beyond the user's balance)
- This would either cause an overflow, unexpected behavior, or loss of funds if the contract doesn't validate input properly
Initial State:
The Attacker contract is deployed and the malicious actor sets up the exploit() function with a token redemption amount that's much larger than their own balance.
Step 1: The attacker calls the exploit() function, which triggers the _redeemPositionToken function with an excessively high token amount (10**30).
Step 2: Since there is no validation in place to check that the amount is within the attacker's balance or is within a reasonable range, the contract processes the redemption, either causing an overflow or transferring an incorrect amount of tokens.
Outcome: The attacker successfully exploits the lack of validation and redeems a large amount of tokens, leading to loss of funds or protocol disruption.
Loss of Funds: The contract might transfer more tokens than expected, resulting in the depletion of assets.
Protocol Instability: Affected functions may become unreliable due to unexpected token transfers or state changes.
Gas Issues: Large operations with unchecked amounts may cause excessive gas usage or failures.
Manual code review
Add Validation Checks: Ensure that the token amounts provided by the user are checked against their balances or other constraints to prevent unexpected or malicious behavior. For example:
Check if the _positionTokenAmount and _wTokenAmount are less than or equal to the sender's balance before proceeding.
Ensure that amounts are non-zero and within a valid range.
Limitations on Maximum Token Amount: Implement limits on the maximum allowed redemption to prevent the user from accidentally or maliciously triggering large transactions that could cause disruptions.
Gas Optimization: Ensure that the added checks do not overly complicate the logic or lead to excessive gas costs.
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.