The withdrawal amount is not deducted from the balance during a withdrawal in the TokenManager.withdraw() function. This oversight allows anyone to call the function multiple times, draining all funds from the protocol.
The issue is straightforward: in the TokenManager.withdraw() function, there is no deduction from the user’s balance when a withdrawal is made. The userTokenBalanceMap mapping is not updated.
For an attacker to exploit this he needs to have a positive balance in userTokenBalanceMap to drain tokens from the CapitalPool contract, to make it happen he would need to:
Create an Ask order with some collateral value, for example 1000 USDC.
Instantly close that order to have the refund amount credited via the TokenManager.addTokenBalance() function.
In case of missing approval from the CapitalPool contract to the TokenManager contract, they can call CapitalPool.approve() for the necessary token, as CapitalPool.approve() lacks access control.
Call the withdraw() function multiple times to drain all funds of the specific token.
All funds can be stolen from the protocol.
Manual review.
Update userTokenBalanceMap to reflect the withdrawn amount of tokens.
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)
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.