cergyk - Solvency checks do not accrue debt on all tokens

[github-actions]

cergyk

high

Solvency checks do not accrue debt on all tokens

Summary

Solvency check on a user position are necessary to ensure that he doesn't put protocol at risk

Vulnerability Detail

Debt on compound style tokens is not accrued when evaluating global position risk for a user, making it possible to take borrows on other markets past health threshold.

getPositionRisk:
https://github.com/sherlock-audit/2023-02-blueberry/blob/main/contracts/BlueBerryBank.sol#L477-L495

getDebtValue:
https://github.com/sherlock-audit/2023-02-blueberry/blob/main/contracts/BlueBerryBank.sol#L451-L475
is based on unaccrued bank.totalDebt value.

Impact

An unsuspecting user can make their position outright liquidatable after a borrow (isLiquidatable returns false before accrual, but true after accrual, so a call to liquidate is successful).

Code Snippet

Tool used

Manual Review

Recommendation

Call accrue on all tokens when calling execute on BlueberryBank

Duplicate of #102

[Gornutz]

While utilizing execute the spell will be doing additional functions that utilize accrue for tokens in the user's position to get the most updated value.

[SergeKireev]

Escalate for 31 USDC

This should be a duplicate of #140
@Gornutz says:

While utilizing execute the spell will be doing additional functions that utilize accrue for tokens in the user's position to get the most updated value.

This is true for the token/position on which the action is executed and is performed by calling the modifier poke on the specific token

Example for borrow:
https://github.com/sherlock-audit/2023-02-blueberry/blob/main/contracts/BlueBerryBank.sol#L713

However position debt is calculated using the debt calculated across all banks, and since debt for tokens of positions for the user A is not accrued it can be underestimated. Another user B can call to accrue these interests later and liquidate user A.

[sherlock-admin]

Escalate for 31 USDC

This should be a duplicate of #140
@Gornutz says:

While utilizing execute the spell will be doing additional functions that utilize accrue for tokens in the user's position to get the most updated value.

This is true for the token/position on which the action is executed and is performed by calling the modifier poke on the specific token

Example for borrow:
https://github.com/sherlock-audit/2023-02-blueberry/blob/main/contracts/BlueBerryBank.sol#L713

However position debt is calculated using the debt calculated across all banks, and since debt for tokens of positions for the user A is not accrued it can be underestimated. Another user B can call to accrue these interests later and liquidate user A.

You've created a valid escalation for 31 USDC!

To remove the escalation from consideration: Delete your comment.
To change the amount you've staked on this escalation: Edit your comment (do not create a new comment).

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[hrishibhat]

Escalation rejected

This is not a duplicate of #140 but of #102
As the issue does not describe multiple token positions as clearly as issue #140 and is considered as duplicate of #102

[sherlock-admin]

Escalation rejected

This is not a duplicate of #140 but of #102
As the issue does not describe multiple token positions as clearly as issue #140 and is considered as duplicate of #102

This issue's escalations have been rejected!

Watsons who escalated this issue will have their escalation amount deducted from their next payout.