Tadle

Tadle
DeFiFoundry
27,750 USDC
View results
Submission Details
Severity: high
Valid

SystemConfig.sol :: updateReferrerInfo() can be used by anyone to modify the rates for any referrer.

Summary

updateReferrerInfo() is designed to adjust the reward rates for a referred user. However, the issue is that this function can be accessed by anyone, allowing any referred user to alter their rates. This vulnerability could be exploited by a malicious user to increase their rewards beyond what the referrer originally intended.

Vulnerability Details

updateReferrerInfo() is implemented as follows.

function updateReferrerInfo(
address _referrer,
uint256 _referrerRate,
uint256 _authorityRate
) external {
if (_msgSender() == _referrer) {
revert InvalidReferrer(_referrer);
}
if (_referrer == address(0x0)) {
revert Errors.ZeroAddress();
}
if (_referrerRate < baseReferralRate) {
revert InvalidReferrerRate(_referrerRate);
}
uint256 referralExtraRate = referralExtraRateMap[_referrer];
uint256 totalRate = baseReferralRate + referralExtraRate;
if (totalRate > Constants.REFERRAL_RATE_DECIMAL_SCALER) {
revert InvalidTotalRate(totalRate);
}
if (_referrerRate + _authorityRate != totalRate) {
revert InvalidRate(_referrerRate, _authorityRate, totalRate);
}
ReferralInfo storage referralInfo = referralInfoMap[_referrer];
referralInfo.referrer = _referrer;
referralInfo.referrerRate = _referrerRate;
referralInfo.authorityRate = _authorityRate;
emit UpdateReferrerInfo(
msg.sender,
_referrer,
_referrerRate,
_authorityRate
);
}

As you can see, this is an external function where all inputs are provided by the user, without any checks to ensure that only the referrer can modify their own referral settings. The only check in place, _msgSender() == _referrer, merely ensures that the referrer doesn't refer to themselves. This lack of proper validation allows any user to modify the rate values.

For example, if the referrer initially sets the reward distribution as 50% for themselves and 50% for the referred user, a malicious referred user could exploit this vulnerability by using another address to alter the distribution, for example changing it to 30% for the referrer and 70% for themselves. Here’s an example scenario:

  • Alice creates a referral link for Bob, setting the reward distribution to 50% for herself and 50% for Bob.

  • Bob notices this and, to bypass the restriction _msgSender() == _referrer (which would revert the transaction if he tried to modify it directly), he uses a different address.

  • Using this other address, Bob changes the distribution to 70% for himself and 30% for Alice.

  • As a result, Bob ends up receiving more rewards than Alice initially intended.

Impact

ReferralInfo can be altered by anyone, potentially causing the referrer to earn fewer rewards.

Tools Used

Manual review.

Recommendations

Implement a system that allows only the referrer to modify their rates, preventing any unauthorized changes by other users.

Updates

Lead Judging Commences

0xnevi Lead Judge 12 months ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-SystemConfig-updateReferrerInfo-msgSender

Valid high severity. There are two impacts here due to the wrong setting of the `refferalInfoMap` mapping. 1. Wrong refferal info is always set, so the refferal will always be delegated to the refferer address instead of the caller 2. Anybody can arbitrarily change the referrer and referrer rate of any user, resulting in gaming of the refferal system I prefer #1500 description the most, be cause it seems to be the only issue although without a poc to fully describe all of the possible impacts

Support

FAQs

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