Frontrun monitoring program to be able to purchase protection for locked pools
Summary
The protocol relies on _assessState() to update the status of poolState.lendingPoolStateDetails[_lendingPool]. This function however does not automatically update every time the user buyProtection() so malicious user may be able to front run off-chain monitoring program to buyProtection() as soon as he detects that there is a missed payment in lending pools. Moreover there may be a large gap before the monitoring program updates the state of pool because it is documented that it will only assessState() daily. If there is a late payment just a few minutes after the pool is assessed, if no one updates the state in place of the program, then there will be a gap of almost 24 hours that malicious buyer will be able to take advantage of.
4.The pool will be locked in the next day when the monitoring program returns to assessState() the pools
Impact
This will cause an asymmetrical situation where the buyer has an advantage over sellers because he will only purchase if the payment is missed, increasing his chance of getting a payout
I don’t think that making off-chain monitoring program that automatically detects the pool state everytime there is a major change in pool status would be helpful because a malicious buyer would still be able to front-run the monitoring program.
I think it is best to assessState() everytime there is a buyProtection() called to ensure that pool status will be updated when the buy happens.
Kumpa
high
Frontrun monitoring program to be able to purchase protection for locked pools
Summary
The protocol relies on
_assessState()to update the status ofpoolState.lendingPoolStateDetails[_lendingPool]. This function however does not automatically update every time the userbuyProtection()so malicious user may be able to front run off-chain monitoring program tobuyProtection()as soon as he detects that there is a missed payment in lending pools. Moreover there may be a large gap before the monitoring program updates the state of pool because it is documented that it will onlyassessState()daily. If there is a late payment just a few minutes after the pool is assessed, if no one updates the state in place of the program, then there will be a gap of almost 24 hours that malicious buyer will be able to take advantage of.Vulnerability Detail
1.Assuming the monitoring program updates
poolStateevery 12:00 amhttps://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/DefaultStateManager.sol#L119-L131
2.In the next hour, there is a missed payment in one of the pools
3.Users will still be able to
buyProtection()even though there is a verifying function_verifyLendingPoolIsActiveto checkpoolStatebecause this function will calldefaultStateManager.getLendingPoolStatus()which pull non-updated status of the pool as shown in the link https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/DefaultStateManager.sol#L273-L2814.The pool will be locked in the next day when the monitoring program returns to
assessState()the poolsImpact
This will cause an asymmetrical situation where the buyer has an advantage over sellers because he will only purchase if the payment is missed, increasing his chance of getting a payout
Code Snippet
https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/DefaultStateManager.sol#L119-L131 https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/DefaultStateManager.sol#L273-L281
Tool used
Manual Review
Recommendation
I don’t think that making off-chain monitoring program that automatically detects the pool state everytime there is a major change in pool status would be helpful because a malicious buyer would still be able to front-run the monitoring program. I think it is best to
assessState()everytime there is abuyProtection()called to ensure that pool status will be updated when the buy happens.Duplicate of #252