DeFiHardhat
35,000 USDC
View results
Submission Details
Severity: low
Invalid

Malicious Actor Can Control The Amount of Tokens received before burning, potentially exploiting the system by burning fewer tokens than intended or none at all

Summary

The chop function in the UnripeFacet contract lacks proper access control, allowing any user or contract to call it with potentially harmful parameters. This lack of access control opens up the possibility for malicious actors to manipulate the token burning process, compromising the integrity of the system.

Vulnerability Details

The vulnerability in the chop function of the UnripeFacet contract stems from the lack of access control, allowing any user or contract to manipulate the token burning process. Let's delve into the details to understand how this vulnerability arises and its potential impact:
The chop function is designed to convert Unripe Tokens into Ripe Tokens according to a specific conversion rate. It is a critical part of the system's functionality, allowing users to exchange Unripe Tokens for their underlying assets.

function chop(
address unripeToken,
uint256 amount,
LibTransfer.From fromMode,
LibTransfer.To toMode
) external payable nonReentrant returns (uint256) {
// burn the token from the msg.sender address
uint256 supply = IBean(unripeToken).totalSupply();
amount = LibTransfer.burnToken(IBean(unripeToken), amount, msg.sender, fromMode);
// get ripe address and ripe amount
(address underlyingToken, uint256 underlyingAmount) = LibChop.chop(
unripeToken,
amount,
supply
);
// send the corresponding amount of ripe token to the user address
require(underlyingAmount > 0, "Chop: no underlying");
IERC20(underlyingToken).sendToken(underlyingAmount, msg.sender, toMode);
// emit the event
emit Chop(msg.sender, unripeToken, amount, underlyingAmount);
return underlyingAmount;
}

Within the chop function, there is a dependency on the burnToken function to burn Unripe Tokens. The burnToken function handles the burning process based on the value of the mode parameter passed to it.
The mode parameter determines the behavior of the burnToken function. If mode is set to EXTERNAL, it directly calls the burnFrom function on the Unripe Token contract, burning tokens from the sender's balance. Otherwise, it calls the receiveToken function , receives tokens, and then burns the received amount.
The vulnerability arises because the chop function is marked as public, meaning it can be accessed by any user or contract in the system without restriction. Malicious actors can exploit this unrestricted access to manipulate the mode parameter and control the token burning process.
By calling the chop function with a custom mode parameter value, malicious actors can bypass the intended burn mechanism. They can control the amount of tokens received before burning, potentially leading to a loss of token value, disruption in system operations, or other adverse effects.

Impact

The lack of access control in the chop function poses a severe risk to the system's integrity and security. Unauthorized manipulation of the token burning process can result in financial losses for users, undermine trust in the platform, and disrupt system operations.

Tools Used

Manual

Recommendations

Add permission checks or access modifiers to ensure that only trusted entities can call the chop function with the correct parameters.

Updates

Lead Judging Commences

giovannidisiena Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Design choice
Assigned finding tags:

Informational/Invalid

Support

FAQs

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