Vault staking request to a DSS cannot be canceled, putting user funds at risk in the case of a malicios DSS

[c4-bot-3]

Lines of code

https://github.com/code-423n4/2024-07-karak/blob/main/src/Core.sol#L146

Vulnerability details

Impact

If an operator no longer wants to stake a vault after submitting a vault staking request, it is not able to cancel that request. Considering the scenario of a malicios/compromised DSS, an operator staking a vault will not be able to cancel their staking request. Furthermore, by design anyone can finalize a staking request. This would put operators at risk of unfair slashing of their funds. This risk is somewhat mitigated by the veto committee which can cancel slashing requests. At the very least the vault funds will be unsuable for the unstaking + staking to new DSS duration of 18 days.

Proof of Concept

There is no function to cancel a staking request and the finalizeUpdateVaultStakeInDSS() function is callable by anyone:

    /// @notice Allows anyone to finish the queued request for an operator to update assets delegated to a DSS
    /// @dev Only operator can finish their queued request valid only after a
    /// minimum delay of `Constants.MIN_STAKE_UPDATE_DELAY` after starting the request
    function finalizeUpdateVaultStakeInDSS(Operator.QueuedStakeUpdate memory queuedStake)
        external
        nonReentrant
        whenFunctionNotPaused(Constants.PAUSE_CORE_FINALIZE_STAKE_UPDATE)
    {
        _self().validateAndUpdateVaultStakeInDSS(queuedStake);
        emit FinishedStakeUpdate(queuedStake);
    }

This means a malicios DSS can finalize vault staking requests even when this is not desireable by the operator.

Consider the following scenario:

An operator wants to stake its vault to a DSS, so it submits a vault staking request via requestUpdateVaultStakeInDSS(). This would set a timer of MIN_STAKE_UPDATE_DELAY = 9 days after which the request can be finalized.

During this time of 9 days, the DSS turns out to be malicios and is unfairly slashing user funds.

The operator cannot remove his request and the malicios DSS finilizes the request by calling finalizeUpdateVaultStakeInDSS() and then slashes the user funds.

The veto commitee does not react on time and the operator loses his funds. Note that even if the veto committee reacts on time, the user funds will be unusable for the duration of unstaking the vault(9) and staking it to a new DSS(another 9 days), since there can be only one stake/unstake request per vault at a time.

Tools Used

Manual Review

Recommended Mitigation Steps

Allow operators to cancel vault staking requests

Assessed type

Other

[c4-judge]

MiloTruck marked the issue as unsatisfactory:
Invalid

[MiloTruck]

This is a design suggestion and not a bug.

There is no issue if vault staking requests cannot be cancelled. Additionally, it is the operator's responsibility to ensure the DSS he chooses does not turn malicious.