Malicious burn nft causes failure to lockCapital() ,seller steady earn PremiumAmount, buyer will be lost compensation
Vulnerability Detail
When the status of the lendingPool changes from Active to Late, the protocol will call ProtectionPool.lockCapital() to lock amount
lockCapital() will loop through the active protections to calculate the lockedAmount.
The code is as follows:
GoldfinchAdapter.calculateRemainingPrincipal()
The current implementation will first determine if the ownerOf the NFTID is _lender
There is a potential problem here, if the NFTID has been burned, the ownerOf() will be directly revert, which will lead to calculateRemainingPrincipal() revert,and lockCapital() revert and can't change status from active to late
Let's see whether Goldfinch's implementation supports burn(NFTID), and whether ownerOf(NFTID) will revert
PoolTokens has burn() method , if principalRedeemed==principalAmount you can burn it
If it can't changes to late, Won't lock the fund, seller steady earn PremiumAmount
So there are two risks
normal buyer gives NFTID to burn(), he does not know that it will affect all protection of the lendingPool
Malicious seller can buy a protection first, then burn it, so as to force all protection of the lendingPool to expire and get the PremiumAmount maliciously. buyer unable to obtain compensation
Suggested try catch for _poolTokens.ownerOf() If revert, it is assumed that the lender is not the owner
bin2chen
high
Malicious seller forced break lockCapital()
Summary
Malicious burn nft causes failure to lockCapital() ,seller steady earn PremiumAmount, buyer will be lost compensation
Vulnerability Detail
When the status of the lendingPool changes from Active to Late, the protocol will call ProtectionPool.lockCapital() to lock amount lockCapital() will loop through the active protections to calculate the
lockedAmount
. The code is as follows:The important thing inside is to calculate the _remainingPrincipal by
referenceLendingPools.calculateRemainingPrincipal()
GoldfinchAdapter.calculateRemainingPrincipal() The current implementation will first determine if the ownerOf the NFTID is _lender
There is a potential problem here, if the NFTID has been burned, the ownerOf() will be directly revert, which will lead to calculateRemainingPrincipal() revert,and lockCapital() revert and can't change status from active to late
Let's see whether Goldfinch's implementation supports burn(NFTID), and whether ownerOf(NFTID) will revert
https://github.com/goldfinch-eng/mono/blob/88f0e3f94f6dd23ebae429fe09e2511650df893a/packages/protocol/contracts/protocol/core/PoolTokens.sol#L199
2.ownerOf() if nftid don't exists will revert with message "ERC721: owner query for nonexistent token"
https://github.com/goldfinch-eng/mono/blob/88f0e3f94f6dd23ebae429fe09e2511650df893a/packages/protocol/contracts/external/ERC721.sol#L136-L138
If it can't changes to late, Won't lock the fund, seller steady earn PremiumAmount
So there are two risks
Suggested try catch for _poolTokens.ownerOf() If revert, it is assumed that the lender is not the owner
Impact
buyer will be lost compensation
Code Snippet
https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/pool/ProtectionPool.sol#L389-L395
https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/adapters/GoldfinchAdapter.sol#L162-L165
Tool used
Manual Review
Recommendation
try catch for _poolTokens.ownerOf() If revert, it is assumed that the lender is not the owner