Tadle

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

referrer cannot update its rates but any other address can for the referrer

Summary

referrer cannot update its rates via systemConfig.updateReferrerInfo but any address can do it for the referrer.

Vulnerability Details

systemConfig.updateReferrerInfo is meant to be used by the referrer to update its _referrerRate and _authorityRate but it cannot call the function to update to its preferred rates. However any random address can call the function and update the rates for the referrer. This is because of the check below which reverts if msg.sender == referrer.

https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/SystemConfig.sol#L46-L48

if (_msgSender() == _referrer) {
revert InvalidReferrer(_referrer);
}

Since this is not an admin function, i believe the check should be msg.sender != referrer instead as this allows the referrer to only change its own rates and prevents any other random address/malicious address from changing rates for another referrer address to whatever it wants.

Proof Of Concept

  • paste code in new file created in /test folder

  • run with forge test

// SPDX-License-Identifier: GPL-2.0-or-later
pragma solidity ^0.8.13;
import {Test, console2} from "forge-std/Test.sol";
import {SystemConfig} from "../src/core/SystemConfig.sol";
import {TadleFactory} from "../src/factory/TadleFactory.sol";
contract SystemConfigTest is Test {
SystemConfig systemConfig;
uint256 basePlatformFeeRate = 5_000;
uint256 baseReferralRate = 300_000;
bytes4 private constant INITIALIZE_OWNERSHIP_SELECTOR =
bytes4(keccak256(bytes("initializeOwnership(address)")));
function setUp() public {
address admin = makeAddr("admin");
TadleFactory tadleFactory = new TadleFactory(admin);
SystemConfig systemConfigLogic = new SystemConfig();
bytes memory deploy_data = abi.encodeWithSelector(
INITIALIZE_OWNERSHIP_SELECTOR,
admin
);
vm.startPrank(admin);
address systemConfigProxy = tadleFactory.deployUpgradeableProxy(
1,
address(systemConfigLogic),
bytes(deploy_data)
);
vm.stopPrank();
// attach logic
systemConfig = SystemConfig(systemConfigProxy);
vm.startPrank(admin);
// initialize
systemConfig.initialize(basePlatformFeeRate, baseReferralRate);
// create market place
systemConfig.createMarketPlace("Backpack", false);
vm.stopPrank();
}
function testUpdateReferral() public {
address referrer = makeAddr("referrer");
//referrer tries to update its rates
vm.prank(referrer);
vm.expectRevert(
abi.encodeWithSelector(
bytes4(keccak256("InvalidReferrer(address)")),
referrer
)
);
systemConfig.updateReferrerInfo(referrer, baseReferralRate, 0); //but this fails
address randomUser = makeAddr("randomUser");
vm.prank(randomUser); //but random user can update rate for the referrer
systemConfig.updateReferrerInfo(referrer, baseReferralRate, 0);
}
}

Impact

referrer cannot update its rates via systemConfig.updateReferrerInfo but any address can do it for the referrer. This means no restriction to storage values and allows for unfair manipulation of a referrer's rates and the referrer is unable to prevent it/remedy the situation.

Tools Used

foundry

Recommended Mitigation Steps

change the check to

if (_msgSender() != _referrer) {
revert InvalidReferrer(_referrer);
}
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.