The Standard

Summary

An attacker can have a tremendous impact on the protocol by making the Liquidation Pool unusable.
The most severe seems to be the incapacity to liquidate undercollateralised vaults.

Vulnerability Details

The Liquidation Pool contract is designed in such a way that a malicious user can have a significant
impact on the overall gas consumption of the contract.

An attacker can register positions with several accounts to add several pending stake.
Those pending stakes are checked on almost every function calls (increasePosition, decreasePosition, distributeAssets).
The more pending stakes and holders are registered, the more gas are required.

Impact

An attacker can have to have two major impacts.

Front-running impact

Position increase

First, a legit user send a transaction to increase its position.

Then, the attacker can front-run the legit transaction to create new pending stakes and new holders.
The pending stakes will be checked during the legit transaction execution, which will increase the
required gas amount and make it fail if the provided gas amount is less than the consumed gas.

Run a liquidation

A legit user sends a transaction to run a liquidation on an undercollateralised vault.

The attacker front-run the legit transaction to create new pending stakes and new holders in the LiquidationPool.

The legit transaction runs the liquidation until the assets distribution in the LiquidationPool.
As a lot of new pending stakes are registered, the gas consumption is insanely high.
As such, the transaction reverts (out-of-gas) and the undercollateralised vault is not liquidated.

Denial of service impact

As the increasePosition has no access control, any attacker can register a lot of small positions
with several accounts. Those positions will be registered as pending stakes.

If too many pending stakes are registered, the increasePosition, decreasePosition and distributeAssets
functions will become unusable as they are cheking those pending stakes and consume a lot of gas.
Those checks are done in the consolidatePendingStakes function.

The most severe impact is due to the high gas consumption in distributeAssets.
As this function is called in the liquidation workflow, it can make revert all the liquidation transactions.
It means that the protocol will not be able to liquidate the undercollateralised vaults.

Tools Used

Scope:

• https://github.com/Cyfrin/2023-12-the-standard/blob/main/contracts/LiquidationPool.sol#L119-L132

• https://github.com/Cyfrin/2023-12-the-standard/blob/main/contracts/LiquidationPool.sol#L136

• https://github.com/Cyfrin/2023-12-the-standard/blob/main/contracts/LiquidationPool.sol#L150

• https://github.com/Cyfrin/2023-12-the-standard/blob/main/contracts/LiquidationPool.sol#L206

Testing code

The following test suite has been added to the liquidationPoolManager.js tests.

Those tests can be run using the command npx hardhat test ./test/liquidationPoolManager.js --grep "zigtur -".

The following results were obtained by adding hardhat-gas-reporter with npm.
Then, the hardhat.config.js file must be modified to add:

Results

The average gas consumption of the LiquidationPool functions are given. They were reported with the hardhat gas reporter on the unit tests.

The difference between the minimum and the maximum correspond to the difference between
the test without any registered holder in the LiquidationPool and the test with 16 holders.

The gas price for increasePosition shows an increase of almost 100%.
More importantly, runLiquidation gas price has been multiplied by more than 6.

An attacker can easily highly increase the required amount of gas for interactions with the Liquidation Pool.
As such, the attacker can make the protocol unusable. This can be heavily impactful on liquidations.

Moreover, as no access control nor emergency withdraw mechanism is set, a scenario in which the
attacker make it unusable and demand for ransom is plausible.

Recommendations

I have found two solutions to mitigate the issue:

• Redesigning the LiquidationPool in a way such that the attacker can't heavily modify the gas consumption.

• A minimum staking amount could be required. For example, 1000 required tokens would require the attacker to have 1000 * number_of_attacking_accounts tokens.