Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The count should be reduced in PaprController.sol#purchaseLiquidationAuctionNFT instead of in PaprController.sol#startLiquidationAuction #267

Open
code423n4 opened this issue Dec 21, 2022 · 8 comments
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-b Q-30 QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax

Comments

@code423n4
Copy link
Contributor

Lines of code

https://github.com/with-backed/papr/blob/9528f2711ff0c1522076b9f93fba13f88d5bd5e6/src/PaprController.sol#L326

Vulnerability details

Impact

Borrowers may be liquidated more assets than needed.
purchaseLiquidationAuctionNFT may perform incorrectly.

Proof of Concept

Because the collateral count is reduced in startLiquidationAuction @ PaprController.sol#L326, the total value and the _maxDebt() of the vault is changed.
This is not correct. The collateral being liquidating should count towards the value of the vault's totalCollateraValue.

For example, maxLTV is 50%, a vault has 10 NFT collaterals (worth 200 papr now) and has a debt of 101 papr, it is liquidatable now.
If the borrower add 1 more collateral to the vault, the vault will be safe (un-liquidatable) again.
But, if someone calls PaprController.sol#startLiquidationAuction first, at this point, if the borrower adds 1 more collateral to the vault, the vault will still be liquidatable.

In extreme cases this can lead to a loop:
a vault become liquidatable -> someone calls startLiquidationAuction() -> borrower add 1 collateral -> someone calls startLiquidationAuction() -> borrower add 1 collateral -> someone calls startLiquidationAuction() -> ...

In general, the borrower is vulnerable to liquidating more collaterals due to the LTV become lower.

The problem may not show up if the previous liquidation auction is always purchased in time, and can be mitigated by using the liquidationAuctionMinSpacing to limit aution intervals.
But the implementation itself is logically incorrect, these mitigation don't really solve it.

In addition, it could cause the isLastCollateral value of purchaseLiquidationAuctionNFT to be incorrect.
When all (multiple) collaterals of a vault have been started the liquidating auctions, because the count is subtracted advanced, the count of the vault is 0 now.
Then all these liquidating collaterals will be treated as the last collateral in purchaseLiquidationAuctionNFT.
As a result, the execution of x will make errors, including fund related errors.

Tools Used

Manual

Recommended Mitigation Steps

  1. Add a mapping to record auctionCount for each vault, increase it when startLiquidationAuction(), reduce it after purchaseLiquidationAuctionNFT().
  2. Include the auctionCount when calculating the total value or _maxDebt() of the vault.
  3. If auctionCount is not 0, removeCollateral, increaseDebt and increaseDebtAndSell are prohibited.
@code423n4 code423n4 added 3 (High Risk) Assets can be stolen/lost/compromised directly bug Something isn't working labels Dec 21, 2022
code423n4 added a commit that referenced this issue Dec 21, 2022
@c4-judge
Copy link
Contributor

trust1995 marked the issue as duplicate of #186

@c4-judge
Copy link
Contributor

trust1995 marked the issue as satisfactory

@c4-judge c4-judge added the satisfactory satisfies C4 submission criteria; eligible for awards label Dec 25, 2022
@c4-judge c4-judge added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value and removed 3 (High Risk) Assets can be stolen/lost/compromised directly labels Jan 4, 2023
@c4-judge
Copy link
Contributor

c4-judge commented Jan 4, 2023

trust1995 changed the severity to 2 (Med Risk)

@c4-judge c4-judge added the downgraded by judge Judge downgraded the risk level of this issue label Jan 4, 2023
C4-Staff added a commit that referenced this issue Jan 6, 2023
@c4-judge c4-judge added QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Jan 7, 2023
@c4-judge
Copy link
Contributor

c4-judge commented Jan 7, 2023

trust1995 changed the severity to QA (Quality Assurance)

@Simon-Busch
Copy link

Remove duplicate-186 label as requested by @trust1995

@Simon-Busch Simon-Busch removed the satisfactory satisfies C4 submission criteria; eligible for awards label Jan 9, 2023
@Simon-Busch
Copy link

Simon-Busch commented Jan 9, 2023

Removed the satisfactory label as well and add grade-b label as requested by @trust1995

@wilsoncusack
Copy link

Dup to #185. We want to remove the NFT at the start of the auction otherwise the borrower could pay down debt, withdraw the NFT, and break the auction logic.

@trust1995
Copy link

It is treated as such. Since #186 was downgraded to QA all finds have been dupped to the warden's QA issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-b Q-30 QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Projects
None yet
Development

No branches or pull requests

6 participants