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

SysytemConfig.sol :: The updateReferrerInfo() incorrectly uses _referrer instead of msg.sender in the referralInfoMap, causing all rewards to be sent to the referred user rather than the referrer.

ivanfitro

Summary

updateReferrerInfo() is designed to modify referral information. However, there's an issue where the referralInfoMap mapping sets referralInfo.referrer to _referrer instead of msg.sender (the user who is refering the new user). This causes the rewards to be sent to the wrong address.

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
);
}

The inputs can be a bit confusing. In this context, _referrer doesn't refer to the address of the person who referred the current user, but rather to the user who was referred by the referrer. This becomes clear in PreMarkets.sol within the createTaker() , where the referralInfo is checked as follows.

ReferralInfo memory referralInfo = systemConfig.getReferralInfo(
_msgSender()
);

Given this, it's clear that in the referralInfoMap mapping, the key represents the referred user, as the referrer will receive a reward for bringing in the new user. When createTaker() is called by the referred user, it retrieves the referralInfo to send rewards to the referrer.

With this in mind, it's evident that referralInfo.referrer = _referrer is incorrectly set, as it should reference the referrer, not the referred user. Instead, it should be set to msg.sender, representing the user who referred the new user. In the current implementation, all rewards are mistakenly sent to the referred user, which is incorrect. The error is evident in the createTaker(), where it calls _updateReferralBonus() to update the rewards.

function _updateReferralBonus(
uint256 platformFee,
uint256 depositAmount,
address stockAddr,
MakerInfo storage makerInfo,
ReferralInfo memory referralInfo,
ITokenManager tokenManager
) internal returns (uint256 remainingPlatformFee) {
///...
tokenManager.addTokenBalance(
TokenBalanceType.ReferralBonus,
@> referralInfo.referrer,
makerInfo.tokenAddress,
referrerReferralBonus
);
​
///...
​
tokenManager.addTokenBalance(
TokenBalanceType.ReferralBonus,
@> _msgSender(),
makerInfo.tokenAddress,
authorityReferralBonus
);
}

As you can see in the current implementation, referralInfo.referrer in the first addTokenBalance() and msg.sender in the second one are the same, meaning all the rewards will be sent to the referred user instead of one to the referrer and the other to the referred. This is because referrerReferralBonus represent the referrer, while authorityReferralBonus is meant for the referred user (trader).

Impact

All the rewards are sent to the referred user, causing the referrer to receive no rewards for bringing in new users. This results in a loss of funds for the referrer.

Tools Used

Manual review.

Recommendations

To resolve this issue, set referralInfo.referrer to the referrer and not to the referred user.

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);
}
//@audit-issue malicious user can set all the retae to referral or autoriry
if (_referrerRate + _authorityRate != totalRate) {
revert InvalidRate(_referrerRate, _authorityRate, totalRate);
}
​
ReferralInfo storage referralInfo = referralInfoMap[_referrer];
- referralInfo.referrer = _referrer;
+ referralInfo.referrer = msg.sender;
referralInfo.referrerRate = _referrerRate;
referralInfo.authorityRate = _authorityRate;
​
emit UpdateReferrerInfo(
msg.sender,
_referrer,
_referrerRate,
_authorityRate
);
}
Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year 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.