Liquidity Management
Gamma
DeFiFoundry
50,000 USDC
View results
Previous Next
Submission Details
Severity: low
Invalid

Centralization Risk for Trusted Owners

glitchunter

Summary

GmxProxy.sol::setMinEth GmxProxy.sol::withdrawEth()
The GmxProxy.sol contract grants the owner privileged control over critical protocol functions, including the ability to modify system parameters and withdraw ETH. This introduces a centralization risk, where a malicious or compromised owner could disrupt operations or drain funds.

Vulnerability Details

The owner can arbitrarily change the minimum ETH balance required for contract operations.

function setMinEth(uint256 _minEth) external onlyOwner {}

If set too high, it could block the protocol’s functionality.

function withdrawEth() external onlyOwner returns (uint256) {}

The owner has unrestricted access to withdraw all ETH from the contract.
If the owner is compromised, they could drain the contract’s ETH holdings.

Impact

Malicious Owner Scenario

If an attacker gains access to the owner account, they could execute the following actions:

  • Set minEth to an excessively high value, preventing any contract operations.

  • Call withdrawEth() to remove all ETH from the contract, leading to a complete loss of funds.

GmxProxy proxy = GmxProxy(contractAddress);
proxy.setMinEth(1000 ether); // Block all transactions
proxy.withdrawEth(); // Drain all funds

  • Funds Theft: A compromised or malicious owner could withdraw all ETH.

  • Denial of Service (DoS): Setting extreme values for minEth could prevent transactions.

  • Protocol Trust Issues: Centralized control contradicts DeFi principles and reduces user confidence.

Tools Used

  • Manual Review

  • Aderyn

Recommendations

  1. Implement a Multi-Signature Governance Model
    Replace onlyOwner with a multi-signature wallet (e.g., Gnosis Safe) to prevent single-party control.

modifier onlyGovernance() {
require(multiSigWallet.isApproved(msg.sender), "Not authorized");
_;
}

  1. Introduce Time-Locked Operations
    Require a time delay before executing privileged functions, allowing users to react.

function scheduleWithdraw(uint256 amount) external onlyOwner {
withdrawalRequestTime = block.timestamp;
}
function executeWithdraw() external onlyOwner {
require(block.timestamp >= withdrawalRequestTime + 24 hours, "Withdrawal delay required");
payable(owner).transfer(amount);
}

  1. Restrict Withdrawals with Hardcoded Limits
    Prevent excessive ETH withdrawals in a single transaction.

require(amount <= MAX_WITHDRAWAL_LIMIT, "Exceeds withdrawal limit");
Updates

Lead Judging Commences

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Admin is trusted / Malicious keepers

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."

n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational or Gas

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.

Admin is trusted / Malicious keepers

Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point. Keepers are added by the admin, there is no "malicious keeper" and if there is a problem in those keepers, that's out of scope. ReadMe and known issues states: " * System relies heavily on keeper for executing trades * Single keeper point of failure if not properly distributed * Malicious keeper could potentially front-run or delay transactions * Assume that Keeper will always have enough gas to execute transactions. There is a pay execution fee function, but the assumption should be that there's more than enough gas to cover transaction failures, retries, etc * There are two spot swap functionalies: (1) using GMX swap and (2) using Paraswap. We can assume that any swap failure will be retried until success. " " * Heavy dependency on GMX protocol functioning correctly * Owner can update GMX-related addresses * Changes in GMX protocol could impact system operations * We can assume that the GMX keeper won't misbehave, delay, or go offline. " "Issues related to GMX Keepers being DOS'd or losing functionality would be considered invalid."

Support

FAQs

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

Give us feedback!