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

Any user can set their own referral rate, or any other user referral rate, leading to excessive fees for the protocol and loss of referral earnings for referrers

0xnbvc

Vulnerability Details

The SystemConfig contract in the Tadle system is responsible for managing referral rates and platform fees. However, the updateReferrerInfo() function in this contract lacks proper access control, which allows any user to modify referral rates arbitrarily.

The function is intended to prevent a user from setting themselves as a referrer by including a check that reverts the transaction if the sender and the referrer are the same. However, this check can be easily bypassed by using a secondary address to set or modify referral rates for the primary address. Consequently, unauthorized users can exploit this loophole to alter referral rates.

This vulnerability exposes two significant risks:

Loss of Legitimate Referral Earnings: A malicious actor can front-run a legitimate transaction to createTaker() by lowering the referral rate associated with a legitimate referrer. This would reduce or eliminate the referral earnings that the legitimate referrer is supposed to receive.

Excessive Fees for the Protocol: An attacker could also increase the referral rate excessively before a transaction is executed, causing the protocol to pay out inflated and illegitimate referral fees.

The lack of proper access control on the updateReferrerInfo() function allows anyone to manipulate referral rates, making the system vulnerable to both loss of legitimate earnings and potential financial exploitation.

SystemConfig.sol#L41-L80

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

Impact

  1. Legitimate referrers losing out on their legitimate referral earnings.

  2. The protocol paying excessive fees.

Proof of Concept

Add this PoC to test/PreMarkets.t.sol and run forge test --mt test_PoC_referral -vvvv:

function test_PoC_referral() public {
// user creates an ask offer
vm.startPrank(user);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
0.01 * 1e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Protected
)
);
​
// Check that user2's referral bonus balance for mockUSDCToken is initially 0
assertEq(tokenManager.userTokenBalanceMap(user2, address(mockUSDCToken), TokenBalanceType.ReferralBonus), 0);
​
// user2 uses a secondary address he controls and updates referrer information for his main address with a 30% referral rate
vm.startPrank(user3);
systemConfig.updateReferrerInfo(user2, 300_000, 0);
​
// user2 creates a taker for the offer
vm.startPrank(user2);
address offerAddr = GenerateAddress.generateOfferAddress(0);
preMarktes.createTaker(offerAddr, 500);
​
// Check that user2's referral bonus balance for mockUSDCToken is now 7500000000000
assertEq(tokenManager.userTokenBalanceMap(user2, address(mockUSDCToken), TokenBalanceType.ReferralBonus), 7_500_000_000_000);
}

Recommendations

Implement proper access control for the updateReferrerInfo() function. Only allow authorized addresses (e.g., platform administrators) to update referral rates. This can be achieved by adding an onlyOwner modifier:

function updateReferrerInfo(
address _referrer,
uint256 _referrerRate,
uint256 _authorityRate
- ) external {
+ ) external onlyOwner {
// Existing checks and logic
}
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.