safdie - Inconsistent cooldown validation in `forceClosePosition` function allows users to exploit timing discrepancies in `ForceActionsFacetImpl.sol`

[sherlock-admin4]

safdie

High

Inconsistent cooldown validation in forceClosePosition function allows users to exploit timing discrepancies in ForceActionsFacetImpl.sol

Summary

Inconsistent cooldown validation in forceClosePosition function in ForceActionsFacetImpl.sol allows users to exploit timing discrepancies.

Root Cause

The function forceClosePosition enforces cooldown periods for various checks. For example: https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/facets/ForceActions/ForceActionsFacetImpl.sol#L64-L65 However, the code does not clearly differentiate between signatures that fail due to cooldown expiration and those that fail for other reasons. This could lead to confusion for users when debugging transactions that revert. Additionally, block.timestamp manipulation attacks are a concern if miners can manipulate the timestamp to circumvent cooldown periods.

The contract has multiple functions that enforce cooldown periods before executing certain actions, but these validations may not be consistently applied across all functions that modify the quote status.

1. Example function with cooldown validation: https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/facets/ForceActions/ForceActionsFacetImpl.sol#L18-L24

2. Function without consistent cooldown check: https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/facets/ForceActions/ForceActionsFacetImpl.sol#L51-L64

An attacker can cancel a quote and then quickly force close the same position using a previously valid signature, circumventing the intended cooldowns on either action. If the attacker manipulates the timing and state changes, they could exploit the inconsistency in cooldown validation.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

1. The attacker initiates a cancellation of a quote.
2. They then attempt to close the same position immediately after canceling, potentially without waiting for the appropriate cooldown to take effect, if validations are inconsistent.
3. Because the cooldown checks are not consistently enforced, the attacker successfully forces the closure of the position.

Impact

1. This vulnerability can lead to unexpected financial gains for the attacker through unauthorized actions. It may also result in losses for affected parties, especially if they are unaware of the cooldown requirements being circumvented.
2. The attacker can manipulate the state of the contract in ways that were not intended by the design, such as: altering positions prematurely or unintended interaction between forced cancellations and closures.

PoC

No response

Mitigation

1. Ensure that all functions that alter quote statuses enforce consistent cooldown checks before proceeding with state changes.
2. Create a centralized function or mechanism to manage cooldowns that can be reused across all relevant functions to ensure uniformity.
3. Implement thorough unit tests to cover various scenarios involving cooldowns and interactions between different functions.
4. Clearly document the cooldown mechanisms in the smart contract code to inform users of the expected behaviors and potential risks.