a malicious user could call the "requestMint" method without having actual collateral in the wallet, he will have the possibility to use an extremely high number as a parameter, such that when the "_checkAndUpdateMintLimit" function is called he will have the possibility of depriving all the others of the possibility of requesting mints for the token in that specific epoch;
the parameter to be able to execute this vulnerability must follow this formula to maximize the damage (amount of mintable tokens and remove the possibility for others to mint)
collateralAmountIn = (mintLimit - currentMintAmount) + ((collateralAmount * mintFee) / BPS_DENOMINATOR)
Proof of Concept
-Bob: call the requestMint method putting as parameter (mintLimit - currentMintAmount) + ((collateralAmount * mintFee) / BPS_DENOMINATOR), even if he doesn't have that collateral,the transaction will call "_checkAndUpdateMintLimit" which will increase "currentMintAmount" to a number equal to mintLimit,the transaction will continue by trying to make safeTransferFrom of the "requestMint" method, which however will not be successful since the actual collateral on the wallet does not exist.
-Alice: she is interested in requesting Mint in that epoch, only there are no more tokens available (she calls "requestMint" with any parameter value, calculates fees, then the method calls "_checkAndUpdateMintLimit" which however causes everything to revert )
furthermore, all the other people who will try to call requestMint at that epoch will fail since they will end up in reverting the call
Lines of code
https://github.com/code-423n4/2023-01-ondo/blob/f3426e5b6b4561e09460b2e6471eb694efdd6c70/contracts/cash/CashManager.sol#L195-L230
Vulnerability details
Impact
a malicious user could call the "requestMint" method without having actual collateral in the wallet, he will have the possibility to use an extremely high number as a parameter, such that when the "_checkAndUpdateMintLimit" function is called he will have the possibility of depriving all the others of the possibility of requesting mints for the token in that specific epoch; the parameter to be able to execute this vulnerability must follow this formula to maximize the damage (amount of mintable tokens and remove the possibility for others to mint) collateralAmountIn = (mintLimit - currentMintAmount) + ((collateralAmount * mintFee) / BPS_DENOMINATOR)
Proof of Concept
-Bob: call the requestMint method putting as parameter (mintLimit - currentMintAmount) + ((collateralAmount * mintFee) / BPS_DENOMINATOR), even if he doesn't have that collateral,the transaction will call "_checkAndUpdateMintLimit" which will increase "currentMintAmount" to a number equal to mintLimit,the transaction will continue by trying to make safeTransferFrom of the "requestMint" method, which however will not be successful since the actual collateral on the wallet does not exist. -Alice: she is interested in requesting Mint in that epoch, only there are no more tokens available (she calls "requestMint" with any parameter value, calculates fees, then the method calls "_checkAndUpdateMintLimit" which however causes everything to revert )
furthermore, all the other people who will try to call requestMint at that epoch will fail since they will end up in reverting the call
Tools Used
Recommended Mitigation Steps
https://github.com/SecurityWalter/Code4Arena/blob/main/Ondo%20Finance/requestMint.sol essentially move the "_checkAndUpdateMintLimit" under the 2 safeTransferFrom