c4-bot-1 commented 9 months ago

Lines of code

https://github.com/code-423n4/2023-12-ethereumcreditguild/blob/2376d9af792584e3d15ec9c32578daa33bb56b43/src/tokens/GuildToken.sol#L214-L217

Vulnerability details

Impact

Users who have assigned guild tokens to a gauge stand to lose those tokens in the case of a loss to the system. When a loan defaults, anyone can call the call function on LendingTerm.sol contract to send it to the auction house. From there, anyone can bid on the loan and take ownership of the collateral if they agree with the price. If the entire collateral is claimed and only a part of the loan is paid back, the system registers this as a loss and slashes the gauge contributors.

The issue is that any user can see a loss coming in from a mile away. They have plenty of time to re-assign the weights of their guild tokens to other gauges. This is because the auction house works in a completely predictable manner.

The Auction house contract uses a 2 stage pricing system. In the first stage, the amount of collateral the liquidator can claim goes up from 0 to 100%. In the second stage, the amount of loan that is required to be paid off goes down from 100% to 0. So any user can calculate the midpoint of the auction and know exactly at which timestamp the chance of a loss can be 100%. The issue is that before that timestamp the chance of slashing is 0%, and after that it jumps to a 100% and that timestamp is already known to everyone.

The variable midPoint is a public variable in the auction house contract which can be read by anyone. Users can listen for the event LoanCall form their staked gauge address, and immediately calculate the midpoint of the auction by checking the Auctionhaouse contract. Users can even check the terms of the loan to be sure if there will be profit or not. If there is no profit, they have until auctionStart+midPoint timestamp to pull out of that gauge. This is a very long time, and users can easily avoid losses by following this simple strategy. There is no need for front or backrunning, simply tracking events is enough.

Since this is the optimal strategy, all users will follow it or deposit into automated systems which will handle this. This will lead to a mad rush of gauge weights going out of the system the moment even a small loss is estimated. Users contributing via the SurplusGuildMinter.sol contract will also pull out the surplus credit tokens which will amplify the chances of accruing bad debt. The less savvy users who staked directly to the gauge will be the ones holding the bags.

Proof of Concept

No POC is provided since this is an MEV related issue.

Tools Used

Manual Review

Recommended Mitigation Steps

Block the _decrementGaugeWeight function in-case an auction for that term is ongoing.

Assessed type

MEV

c4-pre-sort commented 9 months ago

0xSorryNotSorry marked the issue as sufficient quality report

c4-pre-sort commented 9 months ago

0xSorryNotSorry marked the issue as primary issue

eswak commented 8 months ago

I think this is very similar to #343

My comment there :

A resourceful user can monitor the health of all borrower positions, and if they get too dangerous to their taste (or they think the liquidations, if triggered, will result in bad debt), they can redeem in the PSM to get out of the system (assuming borrowers did not redeem and there is enough liquidity to exit). This kind of behavior is encouraged and not considered 'front-running'.

Unstaking from the gauges or redeeming in the PSM is more or less the same, in general the issue is "front running a bad outcome based on readily available information and get out of the system before losses are applied".

This kind of optimal behavior is encouraged (active monitoring & reaction), and when something bad is coming, the exits are mitigated in two ways :

the liquidity in the PSM is limited, so only the unborrowed liquidity can be redeemed against
the gauge weights cannot decrease below a 100% utilization of the debt ceiling, so here again only unborrowed "liquidity" can be decremented from the gauges

c4-sponsor commented 8 months ago

eswak (sponsor) disputed

Trumpero commented 8 months ago

Consider this issue dup of #877 and invalid

c4-judge commented 8 months ago

Trumpero marked the issue as duplicate of #877