ast3ros - [M-2] Credit account can exceed credit limit without penalty

[sherlock-admin]

ast3ros

medium

[M-2] Credit account can exceed credit limit without penalty

Summary

A credit account allows a user, typically a contract, to borrow up to a credit limit without providing collateral. However, there is no mechanism to enforce the credit limit or to liquidate the credit account if it accrues interest beyond the limit.

Vulnerability Detail

A credit account enables a user, typically a contract, to borrow up to the credit limit without providing collateral.

    if (isCreditAccount(from)) {
        require(from == to, "credit account can only borrow to itself");
        require(creditLimits[from][market] >= newUserBorrowBalance, "insufficient credit limit");

https://github.com/sherlock-audit/2023-05-ironbank/blob/main/ib-v2/src/protocol/pool/IronBank.sol#L389-L391

However, when the credit account borrows the maximum limit, and time passes, the interest will accrue and make the user’s borrow balance increase over the credit limit. And there is no mechanism to force the credit account to repay. The credit account cannot be liquidated.

    require(!isCreditAccount(borrower), "cannot liquidate credit account");

https://github.com/sherlock-audit/2023-05-ironbank/blob/main/ib-v2/src/protocol/pool/IronBank.sol#L492

Impact

The credit account can borrow more than its credit limit, which violates the rule of Iron Bank. And there is no mechanism to bring the account back to the credit limit.

Code Snippet

https://github.com/sherlock-audit/2023-05-ironbank/blob/main/ib-v2/src/protocol/pool/IronBank.sol#L389-L391

Tool used

Manual Review

Recommendation

Add a penalty when the credit account has a borrow balance over the credit limit. For example, increase the borrow rate or reduce the credit limit for the account. Alternatively, allow liquidation of the credit account if it exceeds the credit limit by a certain threshold.

[ibsunhub]

From the operation side, we will go through a rigorous review to check the contract before giving the credit limit. For example, the contract must have the ability to profit and ironBank must be the senior debt, etc. Normally, for the safety, we will leave some buffer for the credit limit, but not much. When the credit limit usage is almost full, we will have a discussion to decide if we need to increase the limit. It makes no sense to have a penalty for credit accounts since we expect the credit limit to be just slightly larger than the borrow amount. Not to mention, in the worst scenario, if the credit account won't repay (e.g exploit), adding a penalty won't help at all.

[0xffff11]

According to sponsors explanation, issue is invalid. They will prevent exceeding the credit limit by doing rigorous checks and the proposed fix it does not help in certain scenarios.

[thangtranth]

Escalate for 10 USDC

Thank you sponsor for your input. I respect your opinion, but I would like to highlight the issue here that shows a valid attack vector when a credit account can have its borrow balance over the credit limit, which contradicts the design of the IronBank contract.

If the IronBankv2 relies on rigorous review and off-chain methods to prevent the issue related to credit account, then the credit account related issue should have been declared as out of scope in the beginning. Or the method should be mentioned in the details:

The proposed fix aims to create a negative economic incentive to discourage the normal credit accounts from doing so. It may not be effective in certain scenarios and other solutions may be required, but it does not mean ignoring that the issue exists.

[sherlock-admin]

Escalate for 10 USDC

Thank you sponsor for your input. I respect your opinion, but I would like to highlight the issue here that shows a valid attack vector when a credit account can have its borrow balance over the credit limit, which contradicts the design of the IronBank contract.

If the IronBankv2 relies on rigorous review and off-chain methods to prevent the issue related to credit account, then the credit account related issue should have been declared as out of scope in the beginning. Or the method should be mentioned in the details:

The proposed fix aims to create a negative economic incentive to discourage the normal credit accounts from doing so. It may not be effective in certain scenarios and other solutions may be required, but it does not mean ignoring that the issue exists.

You've created a valid escalation for 10 USDC!

To remove the escalation from consideration: Delete your comment.

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

[0xffff11]

I agree with the miss-communication in the docs. This cases are very complex to judge because given the docs context it is an issue, but in reality, it is not. @hrishibhat what do you think in this case?

[hrishibhat]

Result:
Low
Unique
The credit account role by nature is trusted since you have to trust someone to give them a completely uncollateralized loan.
#98 (comment)

[sherlock-admin2]

Escalations have been resolved successfully!

Escalation status:

• thangtranth: rejected