DSS cannot force jailed operator to unallocate from such DSS

[c4-bot-3]

Lines of code

https://github.com/code-423n4/2024-07-karak/blob/53eb78ebda718d752023db4faff4ab1567327db4/src/Core.sol#L130-L141
https://github.com/code-423n4/2024-07-karak/blob/53eb78ebda718d752023db4faff4ab1567327db4/src/Core.sol#L113-L124

Vulnerability details

Impact

According to https://github.com/code-423n4/2024-07-karak?tab=readme-ov-file#operators, Operators can be jailed by the DSS and one of the effects of jailing is forcing them to unallocate from the DSS. However, the following Core.requestUpdateVaultStakeInDSS and Core.unregisterOperatorFromDSS functions all require msg.sender to be the operator so only the operator can choose to unallocate from the DSS; although the operator is jailed by the DSS, the DSS is unable to call the Core.requestUpdateVaultStakeInDSS function for requesting the unstaking of such operator's vault from the DSS or the Core.unregisterOperatorFromDSS function for unregistering such operator from the DSS. Thus, the DSS fails to force the jailed operator to unallocate from the DSS and cannot prevent all further interactions caused by such operator.

https://github.com/code-423n4/2024-07-karak/blob/53eb78ebda718d752023db4faff4ab1567327db4/src/Core.sol#L130-L141

    function requestUpdateVaultStakeInDSS(Operator.StakeUpdateRequest memory vaultStakeUpdateRequest)
        external
        nonReentrant
        whenFunctionNotPaused(Constants.PAUSE_CORE_REQUEST_STAKE_UPDATE)
        returns (Operator.QueuedStakeUpdate memory updatedStake)
    {
        address operator = msg.sender;
        CoreLib.Storage storage self = _self();
        self.checkIfOperatorIsRegInRegDSS(operator, vaultStakeUpdateRequest.dss);
        updatedStake = self.requestUpdateVaultStakeInDSS(vaultStakeUpdateRequest, self.nonce++, operator);
        emit RequestedStakeUpdate(updatedStake);
    }

https://github.com/code-423n4/2024-07-karak/blob/53eb78ebda718d752023db4faff4ab1567327db4/src/Core.sol#L113-L124

    function unregisterOperatorFromDSS(IDSS dss, bytes memory unregistrationHookData)
        external
        nonReentrant
        whenFunctionNotPaused(Constants.PAUSE_CORE_UNREGISTER_FROM_DSS)
    {
        address operator = msg.sender;
        CoreLib.Storage storage self = _self();
        self.checkIfOperatorIsRegInRegDSS(operator, dss);
        self.unregisterOperatorFromDSS(dss, operator, unregistrationHookData);

        emit UnregisteredOperatorToDSS(operator, address(dss));
    }

Proof of Concept

The following steps can occur for the described scenario.

1. Operator A is registered with DSS A and stakes one of its vaults to DSS A.
2. DSS A detects that Operator A's staked vault is too overleveraged so it jails Operator A.
3. DSS A wants to force Operator A to unallocate from DSS A.
4. Because the Core.requestUpdateVaultStakeInDSS function cannot be called by DSS A for unstaking Operator A's vault from DSS A and the Core.unregisterOperatorFromDSS function cannot be called by DSS A for unregistering Operator A from DSS A, DSS A fails to force Operator A to unallocate from DSS A and cannot prevent all further interactions caused by Operator A.

Tools Used

Manual Review

Recommended Mitigation Steps

The Core contract can be updated to add a function, which is similar to the Core.requestUpdateVaultStakeInDSS function, to only allow a DSS to request the unstaking of its associated operator's vault from such DSS and a function, which is similar to the Core.unregisterOperatorFromDSS function, to only allow a DSS to unregister its associated operator from such DSS.

Assessed type

Other

[c4-judge]

MiloTruck marked the issue as unsatisfactory:
Invalid

[MiloTruck]

Invalid. The README states:

The effects of jailing are also arbitrary and can be decided by the DSS. This can range from no rewards to not allowing the operator to perform any tasks and forcing them to unallocate from the DSS. Jailing is optional and is implemented inside the DSS contract and not the core contract.

"forcing them to unallocate from the DSS" is an example, it is not expected to be implemented in the in-scope code.