HardhatDeFi
15,000 USDC
View results
Submission Details
Severity: medium
Invalid

Lack of Validation on User Input for Token Amounts

Summary

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.

Vulnerability Details

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.

Impact

  • 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

Overview:

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.

Actors:

  • 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.

Working Test Case:

// Assume contract is deployed at address "0xABC..."
// Token address of the ERC20 token
address tokenAddress = 0xDEF...;
// Attacker setup: Deploying a malicious contract that interacts with the AaveDIVAWrapper
contract Attacker {
address public target;
address public user;
constructor(address _target, address _user) {
target = _target; // Address of the AaveDIVAWrapper
user = _user; // Attacker's address
}
// Function to exploit the vulnerability by triggering excessive redemption
function exploit() public {
uint256 maliciousAmount = 10**30; // A very large number, far exceeding the attacker's balance
AaveDIVAWrapper(target)._redeemPositionToken(tokenAddress, maliciousAmount, user);
}
}

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

Exploit Scenario:

  • 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.

Implications:

  • 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.

Tools Used

Manual code review

Recommendations

Recommended Mitigation:

  • 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.

Updates

Lead Judging Commences

bube Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.