Liquidators could front-run repay tx after protocol 'unpausing' event

[c4-bot-4]

Lines of code

https://github.com/code-423n4/2023-12-initcapital/blob/main/contracts/core/InitCore.sol#L535

Vulnerability details

Config allows guardians to effectively 'pause' repayments and liquidation on specified pools and modes by changing the canRepay config variable:

File: InitCore.sol
530:     function _repay(IConfig _config, uint16 _mode, uint _posId, address _pool, uint _shares)
531:         internal
532:         returns (address tokenToRepay, uint amt)
533:     {
534:         // check status
535:         _require(_config.getPoolConfig(_pool).canRepay && _config.getModeStatus(_mode).canRepay, Errors.REPAY_PAUSED);

This could lead to a situation when during the 'unpausing' event liquidators would front-run users who want to repay their unhealthy positions.

Impact

Users that wish to repay their positions could be front-runned by liquidators in case protocol 'pausing' events would take place.

Proof of Concept

Consider the next scenario:

1. Alice creates their own position, collateralizes it, and borrows some funds.
2. Due to some emergency guardian changed the pool config variable 'canRepay' to false, disallowing to repayment and liquidation of affected positions.
3. The price of the collateral changes, making Alice's position unhealthy.
4. Guardian changes 'canRepay' config back to the 'true' value, Alice tries to repay their own position but she is front-runned by the liquidator.

Recommended Mitigation Steps

Consider adding a grace period that would allow users to repay their positions after the 'canRepay' variable is returned to the 'true' value.

Assessed type

Other

[c4-judge]

hansfriese marked the issue as primary issue

[c4-sponsor]

fez-init (sponsor) disputed

[hansfriese]

Frontrunning while repaying looks like an intended behavior although it might be unfair to borrowers after the unpausing event. Want to hear the sponsor's thoughts if any. @fez-init

[c4-judge]

hansfriese marked the issue as unsatisfactory: Invalid

[fez-init]

Actually, this is a valid issue, but should be categorized as low/QA. The suggested mitigation also poses another attack vector that the position may not be liquidatable even if it's very risky already.

[c4-sponsor]

fez-init (sponsor) acknowledged

[c4-sponsor]

fez-init marked the issue as disagree with severity

[c4-judge]

hansfriese marked the issue as satisfactory

[c4-judge]

hansfriese changed the severity to QA (Quality Assurance)

[c4-judge]

hansfriese marked the issue as grade-a