Steadefi
Steadefi
DeFiHardhatFoundryOracle
35,000 USDC
View results
Previous Next
Submission Details
Severity: high
Valid

User can cause a DOS by calling `GMXVaul:withdraw` with a malicious smart contract

NeverGonnaGiveYulUp

Summary

A DOS can be executed on the vault by a user using a malicious contract.

Vulnerability Details

The function GMXWithdraw#processWithdraw attempts to perform a native ETH transfer if WETH is the token meant to be withdrawn:

function processWithdraw(
GMXTypes.Store storage self
) external {
GMXChecks.beforeProcessWithdrawChecks(self);
​
try GMXProcessWithdraw.processWithdraw(self) {
if (self.withdrawCache.withdrawParams.token == address(self.WNT)) {
self.WNT.withdraw(self.withdrawCache.tokensToUser);
(bool success, ) = self.withdrawCache.user.call{value: address(this).balance}("");
require(success, "Transfer failed.");

The call will revert if the target/user is a smart contract without receive or fallback functions. Since the transfer happens in the post-execution block after the try it will not be caught and handled by the catch block. This can be used to create a malicious contract that is able to create deposits and call withdraw from the GMXVault, but does not allow the ETH transfer to complete.

Impact

The vault will be stuck in status Withdraw. While the GMXVault can be opened through the pause-resume flow, a malicious actor can perform the same attack again any time.

Tools Used

Manual Review

Recommendations

Instead of sending native token to the user, send the wrapped asset instead.

Updates

Lead Judging Commences

hans Lead Judge almost 2 years ago
Submission Judgement Published
Validated
Assigned finding tags:

DOS by rejecting native token

Impact: High Likelihood: High An attacker can repeatedly force the protocol to get stuck in a not-open status. This can happen on both deposit, withdraw callback for both successful execution and failures. Will group all similar issues.

Support

FAQs

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