Small loans will never be liquidated, generating bad debt for lenders

[c4-bot-4]

Lines of code

https://github.com/code-423n4/2024-04-lavarage/blob/9e8295b542fb71b2ba9b4693e25619585266d19e/libs/smart-contracts/programs/lavarage/src/processor/swap.rs#L12
https://github.com/code-423n4/2024-04-lavarage/blob/9e8295b542fb71b2ba9b4693e25619585266d19e/libs/smart-contracts/programs/lavarage/src/processor/liquidate.rs#L19

Vulnerability details

Impact

There isn't a minimum position requirement for borrowers when they start a loan.

Malicious borrowers might abuse this to create a large amount of small loans that will be unprofitable to liquidate. This results in a total loss of funds for lenders as they will get only bad debt.

Proof of Concept

1. A malicious borrower starts multiple loans with extremely low amounts of funds borrowed in each one, in a single transaction (by chaining borrow - add_collateral - borrow - ... with different positions on the same pool). They get the same amount of funds as they would have got with a single big loan AND they pay just for a single transaction.
2. When the LTV goes > 90% the lender should liquidate each of these loans, but it will be unprofitable to do so as they NEED to execute and pay for multiple transactions.
3. The lender will never liquidate all the loans (as it's unprofitable) so they only get bad debt.

Tools Used

Manual review

Recommended Mitigation Steps

Consider implementing a minimum amount to start a loan.

Assessed type

Invalid Validation

[c4-sponsor]

piske-alex (sponsor) confirmed

[c4-judge]

alcueca marked the issue as satisfactory

[c4-judge]

alcueca changed the severity to 2 (Med Risk)

[c4-judge]

alcueca marked the issue as primary issue

[c4-judge]

alcueca marked the issue as selected for report

[DadeKuma]

Can I get an explanation about why this was downgraded? Note that this is not about the borrowing fees not being paid like the QA report that was duped.

This issue has the same impact as #10, but a different mitigation: borrowers are able to steal the borrowed funds and they will never repay these loans (liquidating these loans would be a loss for the lender as the TX cost will be higher than the loaned amount), please re-check.

[Arabadzhiew]

Sorry, but I don't understand how this exploit is supposed to work. Can't a bunch of liquidation instructions be executed in one transaction just like with the borrow instructions? Also, based on the fact that with the current state of protocol the borrowers will have to deposit a rent exemption amount of SOL into each of their borrow position PDAs, this will make the exploit non-profitable for them to perform (see #14 for more information about that, but the TL;DR is that this issue will actually act as a protection against that one).

Therefore, based on those two things, I actually believe that this issue should be downgraded to QA, as there is currently no financial incentive to perform it.

[DadeKuma]

Can't a bunch of liquidation instructions be executed in one transaction just like with the borrow instructions?

No, because the oracle needs to sign the liquidation transaction, while borrow can be freely chained with multiple instructions as the user signs the transaction.

Also, based on the fact that with the current state of protocol the borrowers will have to deposit a rent exemption amount of SOL into each of their borrow position PDAs

This is false, since Anchor 0.24.x there's no need to send the rent exemption amount, and the protocol is using Anchor 0.29.0, you can find more info here; so #14 is inaccurate

[Arabadzhiew]

No, because the oracle needs to sign the liquidation transaction

So you mean to tell me that the oracle can't sign more than one instruction? This sounds like a pretty strong external assumption to me.

This is false, since Anchor 0.24.x there's no need to send the rent exemption amount

That is not true. Rent is a core concept of the Solana blockchain and creating an account without paying rent for it will lead to it being instantly closed. You can read more about it in this resource from the Solana docs. The comment from Stackexchange that you have linked to seems to be referring to a Rent property of the Anchor #[init] account attribute.

[rvierdiiev]

While i am new to Solana, but during the audit i have read docs that all new accounts now should be rent for 2 years. Paying by epochs will work only for older accounts. Also think this will be expensive to pay for each data account.

[DadeKuma]

I'm not entirely sure about this as I'm new to Solana, but I think it depends on which Solana version is used to compile the program. The latest Solana version enforces rent-exempt accounts, but older versions permit users to pay rent every epoch; Anchor has the rent_exempt constraint to enforce rent exemption with new accounts manually.

[rvierdiiev]

As in Ethereum we have nodes, which are Ethereum clients(geth for example) in same way in Solana they have smth similar. And in the docs we see that now their execution clients are updated, so they will not allow tx to create data accounts that are not rent exempt.

[DadeKuma]

I see, thank you for your explanation, TIL. If this is the case, the attack is not economically profitable.

[alcueca]

The attack is not economically profitable. If it were, this would be a critical. However, it can be used as a means of hurting the lenders, and the protocol as a whole, at a cost. As a griefing attack, it is a Medium.

[rvierdiiev]

@alcueca What i don't understand how it can be medium if no one will do that? What do you mean griefing here?

[piske-alex]

like making the lender lose money without profiting him/herself financially

[alcueca]

As the sponsor said, malicious users (or rival protocols) would be willing to spend money to hurt the protocol.