Lido – Node Operator can exit and slash their validator to move withdrawal finalization border epoch

Bypassing the border epoch as determined by the mass slashing event.

Vulnerability Details

During a mass slashing event, the withdrawal queue may delay finalization of withdrawal requests in queue.

The get_safe_border_epoch function, which determines the border epoch for unlocking withdrawal requests, relies on the _get_associated_slashings_border_epoch function to compute this epoch based on the ongoing mass slashing activity.

In a mass slashing scenario, this function returns the most recent epoch before the slashing commenced. This epoch is determined as the earliest slashed_epoch among all validators with incomplete slashings at the time of the reference_epoch, rounded to the beginning of the most recent oracle report frame.

A challenge arises because the slashed_epoch field is not present in the validator data; it must be inferred. If the difference between a validator’s withdrawable_epoch and exit_epoch equals MIN_VALIDATOR_WITHDRAWABILITY_DELAY, it suggests a large exit queue, making it difficult to ascertain the precise slashed_epoch. Conversely, if this condition does not hold, the slashed_epoch can be estimated as withdrawable_epoch - EPOCHS_PER_SLASHINGS_VECTOR

The core problem lies in the Oracle’s assumption that the earliest exit_epoch corresponds to one of the validators involved in the mass slashing. A dishonest operator could anticipate a mass slashing event and proactively exit one of their validators.

Consequently, when the mass slashing occurs, the border epoch is calculated using the exit epochs of the validators being slashed. If the operator slashes their validator before it officially exits, the earliest exit_epoch will belong to that validator, resulting in a situation where the safe border is determined by its intentional slashing.

This effectively allows withdrawals submitted after the onset of the mass slashing to be unlocked.

Attack scenario

The attackers might take the following steps in sequence:

1. A sophisticated operator managing multiple validators detects a potential mass slashing event.
2. The operator exits one of their validators at time t0. This sets the exit epoch to t10 = t0 + 10 and the withdrawable epoch to t20 = t0 + 20 (reflecting the minimum withdrawability delay).
3. A mass slashing event begins at time t5. The first slashed validators have an exit epoch set at t15 = t5 + 10 and a withdrawable epoch at t105 = t5 + 100 (based on epochs per slashing).
4. The operator confirms the mass slashing and submits a withdrawal request at time t8, but it is blocked due to the active mass slashing, which establishes the safe border at t5 (the slashed epoch of a validator with the earliest exit epoch).
5. The operator proceeds to slash the validator from step 2 at time t9. Consequently, the earliest exit_epoch will now be associated with the operator’s validator, and the slashed epoch becomes t9. This action unlocks all withdrawal requests made between t5 and t9, which should have been blocked.