Skip to content

Latest commit

 

History

History
54 lines (34 loc) · 3.08 KB

077.md

File metadata and controls

54 lines (34 loc) · 3.08 KB

Calm Sandstone Shell

High

Untrusted token burn vulnerability in burnStableTokens()

Summary

The burnStableTokens function is susceptible to attacks when dealing with untrusted or malicious tokens. Specifically, the function’s reliance on safeTransferFrom and safeBurn allows a malicious token contract to exploit these methods, potentially causing reentrancy attacks or enabling fake burn behaviors. These issues arise because of the lack of validation for the token address, allowing any token contract with a compatible interface to interact with burnStableTokens without restriction. https://github.com/sherlock-audit/2024-10-mento-update/blob/main/mento-core/contracts/swap/Broker.sol#L187-L191

Root Cause

The lack of validation or control over the token parameter.

  1. Reentrancy Vulnerability: safeTransferFrom or safeBurn could call back into Broker due to custom logic in the token contract, causing reentrancy issues.
  2. Fake Burn Behavior: Malicious tokens may implement a burn function that does not correctly reduce the token balance, allowing repeated and unintended calls to burnStableTokens.
  3. Unintended Transfer Logic: Custom or manipulated safeTransferFrom and safeBurn functions could lead to unverified token transfers, draining funds from either the contract or the user.

Internal pre-conditions

  1. msg.sender must call burnStableTokens with a valid token and amount parameter.
  2. The ERC-20 token contract for token must implement safeTransferFrom and burn (either directly or via safeBurn), but the contract does not verify whether these methods are standard or have safe behaviors.

External pre-conditions

  1. The token contract may have custom implementations for safeTransferFrom and safeBurn, which can include:
  • Callback functions that invoke reentrancy paths.
  • Non-standard behaviors that don’t deduct tokens as expected.
  1. The user’s wallet has sufficient balance and approval set up for the contract to execute safeTransferFrom.

Attack Path

Reentrancy Attack

A malicious token contract overrides safeTransferFrom or safeBurn with a callback function that re-enters Broker, potentially leading to unexpected behaviors, state manipulation, or draining of funds.

Fake Burn Behavior

A malicious token contract implements a burn function that doesn’t actually reduce the contract’s token balance, allowing the attacker to call burnStableTokens multiple times without ever reducing the total token balance, thereby allowing a “free burn” for fake tokens.

Unexpected Fund Transfers

By overriding safeTransferFrom, a malicious token could transfer funds unexpectedly (e.g., from other addresses), potentially draining user accounts or creating imbalances.

Impact

No response

PoC

No response

Mitigation

Implement checks to verify successful balance reductions after a burn, ensuring the contract’s balance is reduced as expected. Use standard libraries like OpenZeppelin's SafeERC20 to wrap ERC-20 calls, which includes additional checks and ensures safe execution. Add a nonReentrant modifier to burnStableTokens to prevent reentrancy attacks.