PartyB can leverage emergency mode for quick profits
Summary
PartyB can leverage emergency mode for quick profits via front-running.
Vulnerability Detail
In the previous Sherlock, an issue related to PartyB's ability to leverage emergency mode for quick profits was raised. The full report can be found below:
In the new changes in version 0.8.3, per the documentation, the explanation for the changes in emergencyClosePosition function is as follows:
From time to time, Binance delists some of its pairs. In the current version, we, as a platform, had to put partyBs in emergency mode to let them close their positions without users' requests. In the next version, if a symbol becomes invalid, partyB can emergency close all its positions
The key takeaway from this change is that emergency mode will automatically be triggered when Binance delists some of its pairs. In other words, in the new setup, malicious PartyB would no longer need to deceive the protocol admins first to trick them into enabling the emergency for them. They simply have to wait for the opportunity to come by when the protocol marks a symbol as invalid. As the documentation stated, it will happen from time to time. Thus, this event will definitely happen at some point.
As a result, the precondition of needing to deceive the protocol admin first in order for the issue to be realized is no longer sufficient to be used to mitigate this issue. The new changes result in the issue re-surfacing and the risk being realized.
Bob, the malicious PartyB, sees the transaction to mark a symbol as invalid in the mempool. He front-runs the TX and opens any profitable positions, as mentioned in the original report. Once the transaction to mark a symbol as invalid is executed on-chain, he could close them for a profit.
[!NOTE]
The Symbol.isValid check here does not prevent this attack. Bob is front-running the protocol's "Mark Symbol Invalid" transaction. Thus, when Bob's open position transactions are executed, the symbol is still valid on-chain.
To mitigate the risk of this issue, any transaction to delist a symbol from the protocol should be submitted to a private mempool instead of public mempool to reduce the chance of malicious PartyB from noticing the transaction and front-running it to exploit this issue.
xiaoming90
Medium
PartyB can leverage emergency mode for quick profits
Summary
PartyB can leverage emergency mode for quick profits via front-running.
Vulnerability Detail
In the previous Sherlock, an issue related to PartyB's ability to leverage emergency mode for quick profits was raised. The full report can be found below:
The issue has been rejected due to the reasons that malicious PartyB would first need to deceive the protocol admins first to trick them into enabling the emergency for them. Following are the old comments from the protocol for reference (https://github.com/sherlock-audit/2023-08-symmetrical-judging/issues/33#issuecomment-1722461404)
In the new changes in version 0.8.3, per the documentation, the explanation for the changes in
emergencyClosePositionfunction is as follows:The key takeaway from this change is that emergency mode will automatically be triggered when Binance delists some of its pairs. In other words, in the new setup, malicious PartyB would no longer need to deceive the protocol admins first to trick them into enabling the emergency for them. They simply have to wait for the opportunity to come by when the protocol marks a symbol as invalid. As the documentation stated, it will happen from time to time. Thus, this event will definitely happen at some point.
As a result, the precondition of needing to deceive the protocol admin first in order for the issue to be realized is no longer sufficient to be used to mitigate this issue. The new changes result in the issue re-surfacing and the risk being realized.
Bob, the malicious PartyB, sees the transaction to mark a symbol as invalid in the mempool. He front-runs the TX and opens any profitable positions, as mentioned in the original report. Once the transaction to mark a symbol as invalid is executed on-chain, he could close them for a profit.
Impact
Medium impact as per the original report.
Code Snippet
https://github.com/sherlock-audit/2024-06-symmetrical-update-2/blob/main/protocol-core/contracts/facets/PartyB/PartyBFacetImpl.sol#L267
Tool used
Manual Review
Recommendation
To mitigate the risk of this issue, any transaction to delist a symbol from the protocol should be submitted to a private mempool instead of public mempool to reduce the chance of malicious PartyB from noticing the transaction and front-running it to exploit this issue.