Part 2
Zaros
PerpetualsDEXFoundrySolidity
70,000 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

A Malicious user can steal others assets

ifexx445

Summary

In the VaultRouterBranch.sol contract, the redeem function contains a critical vulnerability where a malicious user can frontrun legitimate transactions. This is because the function does not verify that msg.sender matches the withdrawal request creator stored in vaultRequestIdCounter. Without this verification, a malicious actor can craft a withdrawal request ID that corresponds to another user's legitimate request and redeem assets belonging to them by passing in there withrawal request id.

Vulnerability Details

/// @param vaultId The vault identifier.
/// @param withdrawalRequestId The previously initiated withdrawal request id.
/// @param minAssets The minimum amount of collateral to receive, in the underlying ERC20 decimals.
@> function redeem(uint128 vaultId, uint128 withdrawalRequestId, uint256 minAssets) external {
// fetch storage slot for vault by id
Vault.Data storage vault = Vault.loadLive(vaultId);
​
// load storage slot for previously created withdrawal request
WithdrawalRequest.Data storage withdrawalRequest =
@> WithdrawalRequest.loadExisting(vaultId, msg.sender, withdrawalRequestId);
​
// revert if withdrawal request already fulfilled
if (withdrawalRequest.fulfilled) revert Errors.WithdrawalRequestAlreadyFulfilled();
​
// revert if withdrawal request delay not yet passed
if (withdrawalRequest.timestamp + vault.withdrawalDelay > block.timestamp) {
revert Errors.WithdrawDelayNotPassed();
}
​
// prepare the `Vault::recalculateVaultsCreditCapacity` call
uint256[] memory vaultsIds = new uint256[]();
vaultsIds[0] = uint256(vaultId);
​
// updates the vault's credit capacity before redeeming
Vault.recalculateVaultsCreditCapacity(vaultsIds);
​
// define context struct, get withdraw shares and associated assets
RedeemContext memory ctx;
ctx.shares = withdrawalRequest.shares;
ctx.expectedAssetsX18 = getIndexTokenSwapRate(vaultId, ctx.shares, false);
​
// load the mm engine configuration from storage
MarketMakingEngineConfiguration.Data storage marketMakingEngineConfiguration =
MarketMakingEngineConfiguration.load();
​
// cache vault's redeem fee
ctx.redeemFee = vault.redeemFee;
​
// get assets minus redeem fee
ctx.expectedAssetsMinusRedeemFeeX18 =
ctx.expectedAssetsX18.sub(ctx.expectedAssetsX18.mul(ud60x18(ctx.redeemFee)));
​
// calculate assets minus redeem fee as shares
ctx.sharesMinusRedeemFeesX18 =
getVaultAssetSwapRate(vaultId, ctx.expectedAssetsMinusRedeemFeeX18.intoUint256(), false);
​

As we can see no verification of the caller of redeem function all the malicious user has to do is call the redeem before the honest user using his withdrawal request id and all the user shares will be converted to assets for the malicious users

Impact

Unauthorized withdrawal of others assets

Tools Used

Manual audit

Recommendations

Verify the redeem function of msg.sender

Updates

Lead Judging Commences

inallhonesty Lead Judge
7 months ago
inallhonesty Lead Judge 6 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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