code-423n4 / 2024-07-karak-validation

0 stars 0 forks source link

DSS is still allowed to slash after MIN_WITHDRAWAL_DELAY is passed #355

Closed c4-bot-4 closed 2 months ago

c4-bot-4 commented 2 months ago

Lines of code

https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/SlasherLib.sol#L129

Vulnerability details

Impact

1 no check to find whether the VETO_WINDOW is over for cancelSlashing. VETO can still slash even after veto is over. 2 DSS is still allowed to slash after MIN_WITHDRAWAL_DELAY is passed

Proof of Concept

Problems :

1) Veto can cancel the slash even after the SLASHING_VETO_WINDOW has passed. DSS can front run slashing before the cancelSlashin event.

After a slash request is generated, a two-day period is allotted for the slashing committee to review and potentially veto the request. If the committee decides against vetoing, the finalizeSlashing function can be called to execute the slashing process." https://docs.karak.network/developers/dss/karak-interactions#slashing-mechanism-in-dss

2) DSS can finish slash event even after MIN_WITHDRAWAL_DELAY ( SLASHING_WINDOW + SLASHING_VETO_WINDOW) has passed. User can front run the slashevent by redeeming the shares.
This can result in those users to avoid slashing lose and other users to suffer more loss.

DSS and veto should be strictly contained inside the timeinterval where they can do their duties.

Righ now we are having a loose checks.

https://github.com/code-423n4/2024-07-karak/blob/f5e52fdcb4c20c4318d532a9f08f7876e9afb321/src/entities/SlasherLib.sol#L129

        if (queuedSlashing.timestamp + Constants.SLASHING_VETO_WINDOW > block.timestamp) 

Tools Used

Manual

Recommended Mitigation Steps

Assessed type

Context