Attacker can make his stake immune to `verifyOvercommittedStake`.

[code423n4]

Lines of code

https://github.com/code-423n4/2023-04-eigenlayer/blob/main/src/contracts/pods/EigenPod.sol#L175-L226 https://github.com/code-423n4/2023-04-eigenlayer/blob/main/src/contracts/pods/EigenPod.sol#L241-L294

Vulnerability details

Impact

verifyOvercommittedStake for an EigenPod will be DOSed, and Attacker's shares will never be reduced even when his stake on BeaconChain gets slashed, and someone attempts to record the overcommitment.

Proof of Concept

Here is the verifyWithdrawalCredentialsAndBalance function: L175-L226 And the verifyOvercommittedStake function: L241-L294

Imagine this scenario:

• Alice is a validator on BeaconChain
• Alice staked 32ETH at block 15000, with withdrawalCredentials pointed to her EigenPod
• Alice gets slashed on BeaconChain for malicious act
• Alice stakes ETH again on BeaconChain with withdrawal credentials pointed to her own address.
• After 50400 blocks(7 days), at block 65400, Alice calls EigenPod's verifyWithdrawalCredentialsAndBalance with oracleBlockNumber of 15000, validatorIndex that is still INACTIVE, proofs from block 15000, and validatorFields from block 15000.
  • The function checks validatorCurrentBalanceGwei which is now 32ETH (because Alice staked again)
  • fetches beacon state root at block 15000, and verifyValidatorFields and verifyValidatorBalance which would both pass.
  • EigenPodManager.restakeBeaconChainETH will then be called which would increment the podOwner's shares by 32
• Now, calling verifyOvercommittedStake should decrease the podOwner's shares because the ETH which points to EigenPod has been slashed on BeaconChain.
• Anyone that tries to decrease podOwner's shares by calling verifyOvercommittedStake will fail because:
  • The function cannot be called with oracleBlockNumber older than 50400 blocks
  • For the past 50400 blocks, validator's ETH has not been slashed. Therefore, L257 will revert

Tools Used

Manual Review

Recommended Mitigation Steps

In the verifyWithdrawalCredentialsAndBalance function, verify against the current beaconStateRoot or a very recent beaconStateRoot as it was done in verifyOvercommittedStake function, instead of allowing user to input an arbitrary oracleBlockNumber:

require(oracleBlockNumber + VERIFY_OVERCOMMITTED_WINDOW_BLOCKS >= block.number,
            "EigenPod.verifyOvercommittedStake: specified blockNumber is too far in past");

Assessed type

DoS

[0xSorryNotSorry]

It looks like a different attack approach to the same mitigation of https://github.com/code-423n4/2023-04-eigenlayer-findings/issues/374

[c4-pre-sort]

0xSorryNotSorry marked the issue as primary issue

[c4-sponsor]

Sidu28 marked the issue as sponsor disputed

[Sidu28]

"It is not possible to change existing 0x01-type withdrawal credentials of a pubkey, even a fully exited one. Alice cannot ""stakes ETH again on BeaconChain with withdrawal credentials pointed to her own address"" if she is staking to the same validator. So there are two cases: 1) Alice stakes to the same validator, so is not overcommitted 2) Alice stakes to a different validator, so is indeed overcommitted and can be proved to be overcommitted Neither of these cases is an issue."

[GalloDaSballo]

With the info I have, I agree with the Sponsor

[c4-judge]

GalloDaSballo marked the issue as unsatisfactory: Insufficient proof