KrisRenZo - Attacker can extract more funding fees by blockstuffing

[sherlock-admin2]

KrisRenZo

High

Attacker can extract more funding fees by blockstuffing

Summary

Due to one of the multiplying factors for how much funding fee traders receive being reliant on block.timestamp, an attacker can manipulate the system in their favor by stretching out the fundingFeeDurationInSecond.

Vulnerability Detail

Relevant design details

• longPayShort determine if shorts or long earns funding fee that has accrued for fundingFeeDurationInSecond.
• longPayShort is determined by comparing totalLongOpenInterest to totalShortOpenInterest; whichever is greater, pays the other.
• funding fee is updated when getUpdateMarketFundingFeeRate is called, which is only called during order execution or position liquidation.
• fundingFeeDurationInSecond is the time since the last funding fee was paid and it is a multiplying factor for totalFundingFee received by traders

Attacker can prevent the processing of orderExecution or liquidation Txs through blockstuffing, in order to extend the fundingRatePerSecond used as a multiply factor to calculate their funding fee, effectively stealing from their counter traders. It is conceivable for such an attack to be coordinated by a group of traders on the same side of a trade. By default, everyone on their side profits fairly from it, and can share the risk evenly. To take the attack a step further, attackers seize the blockspace until the set of txs in the mempool favors them, leaving their counter traders with little to no chance of accruing funding fees. The higher the fundingRatePerSecond the more attractive the risk to reward ratio for this attack becomes.

This is feasible because no matter the amount of open interest against their positions, it doesn't impact price movement as it is a perpetual market. Therefore the only cost of this attacker is the transaction fee for holding the blockspace, which is significantly cheap on layer2s. Additionally the more the open interest for the opposing side of their trade builds up, the more funding fee they receive, further incentiving them to continue the attack indefinitely.

Code Snippet

https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/8a1a01804a7de7f73a04d794bf6b8104528681ad/elfi-perp-contracts/contracts/process/MarketQueryProcess.sol#L124

https://github.com/sherlock-audit/2024-05-elfi-protocol/blob/8a1a01804a7de7f73a04d794bf6b8104528681ad/elfi-perp-contracts/contracts/process/MarketQueryProcess.sol#L130-L133

Impact

Loss of reward for traders on the opposing end of the attacker's trader and unfair reward distribution

Tool used

Manual Review

Recommendation

Implement the FundingFee such that the longer the longPayShort bias continues, the lesser the fundingRatePerSecond. Alternatively, work around having to rely critically on block.timestamp for calculating

[nevillehuang]

request poc

This issue is highly theoretical, how likely is blockstuffing on the supported chains especially when mempool is private? Will it even be profitable with how much it costs to execute a blockstuffing attack? This issues lack details on the economic feasibility of blockstuffing vs potential profits. Same for issue #192

[sherlock-admin4]

PoC requested from @Renzo1

Requests remaining: 14

[Renzo1]

This issue is highly theoretical, how likely is blockstuffing on the supported chains especially when mempool is private?

Blockstuffing is just as likely on these chains as it is everywhere else as long as the delayed function is time-sensitive.

It doesn't matter that the mempool is private; as long as the sequencer can select and process the attacker’s transaction and the network blocks have gas limit, this attack can happen.

The key factor in blockstuffing is delaying a time-sensitive function by occupying block space by exhausting the gas limit. This is also applies to finding #192.

Will it even be profitable with how much it costs to execute a blockstuffing attack? This issues lack details on the economic feasibility of blockstuffing vs potential profits. Same for issue https://github.com/sherlock-audit/2024-05-elfi-protocol-judging/issues/192

You make a good point about the economic feasibility of the attack, but perhaps you are overestimating the cost of blockstuffing and failing to consider this factor: the cost of the attack is fixed, while the possible profit is only limited by the size of the market.

To clarify the economic feasibility of this attack: at the time of writing, the cost of this attack (block gas limit x gas price) on Arbitrum is $10.94.

In a large market where the total open interest of funding fee payers is so significant that the funding fee paid per block time exceeds the exploit cost (which is barely above $10), this attack becomes easily profitable.

Furthermore, the larger the protocol grows, the greater the potential profit for the attackers.

PoC requested from @Renzo1

Regarding a Proof of Code, blockstuffing isn't one of those vulnerabilities that can be demonstrated with foundry/hardhat, as the exploit takes effect within the network blocks, and these tools don't provide such a level of granularity.

@nevillehuang