Anybody can front-run accruePremium..() and receive rewards as if they had provided protection since last accrual

Summary

The accruePremium() function can be front-run, sellers can wait until just before a payment to deposit and by doing so they can receive premium rewards for period before they deposited.

Vulnerability Detail

Premium is accrued when a new payment has been made. The amount accrued is based on the following formula: $$AP = K \cdot (e^{-t\cdot \lambda}-e^{-T\cdot \lambda})$$ Where $t$ will be the time until the latest premium accrual and $T$ the time until the latest payment. The accrued amount is distributed to sToken holders in the following code (350 ProtectionPool)

The accrued amount is added to the underlying amount that sToken holders later can claim. The accrual is therefore distributed in proportion to how many sToken seller own. This can be seen in the accruePremiumAndExpireProtections() function:

https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/pool/ProtectionPool.sol#L344-L347

If a seller waits until right before a payment is made and front-runs the accruePremium() they will receive have bought into the pool before the accrual happens. By doing so they receive payments for a full payment term without having provided any capital.

The following can be read in the docs:

"Sellers can make a deposit at any time but will only accrue premium from the date of deposit up to the date of next payment term in the underlying lending pool. With this design, we prevent sellers from earning interest without being exposed to default risk."

This does not hold based on this vulnerability

Impact

Seller that time their entries steal from other sellers, they receive a proportional amount of the accrued premium for the previous term without having been exposed to any risk. The depositor steals a proportional amount to how large their share of the sToken are.

In a ProtectionPool with many different lendingpools the seller would select the pool with the largest premium accrual to maximize how much unearned premium they can steal.

Code Snippet

https://github.com/sherlock-audit/2023-02-carapace/blob/main/contracts/core/pool/ProtectionPool.sol#L344-L347

Tool used

Manual Review, vscode, foundry

Recommendation

Accrual should only be made to users in proportion to how long they have provided capital during a payment duration. The accrual functionality has to be re-written to not blindly issue sToken to everybody but take into account that seller can enter at any point during a payment term. They should be rewarded in proportion the time spent providing protection.

Duplicate of #26

sherlock-audit / 2023-02-carapace-judging

monrel - Anybody can front-run accruePremium..() and receive rewards as if they had provided protection since last accrual #294