Deposit contract exploit

There is a front-running exploit in the deposit contract that allows validator key holders to front-run withdrawal key holders and steal their funds. The exploit goes as follows:

  1. “friendly staking service” (FSS) offers to run a validator for a user, with the user retaining access to their funds via the withdrawal key
  2. FSS creates deposit data for the user to sign and broadcast to mainnet
  3. FSS also creates an exploiting deposit data, with the same validator key but FSS’ own withdrawal credentials
  4. When the user broadcasts their deposit transaction to Ethereum mainnet FSS front-runs it with the exploiting deposit transaction
  5. Result is the user’s deposit is accepted with FSS’ withdrawal credentials

The general issue is that there is no check that a given deposit is either new or has the same withdrawal credentials if its validator key matches one for a previous deposit.

4 Likes

This is not possible as the Eth1 Tx you submit is only valid over the function inputs you sign for, meaning that “FFS” cannot submit a valid Tx sending 32 ETH from your account.

Secondly, this is not a general exploit of the deposit contract, only the specific case whereby you trust a third party to do the validation on your behalf. In this case you already need to trust them to the extent that they can get your funds slashed.

1 Like

They aren’t sending Ether from user’s account, they are sending a deposit from their own account. The important points are:

  • both deposits have the same validator pubkey in the deposit data
  • the exploiter’s transaction is processed first

Note the exploiter does not need to send a full 32 Ether deposit, they could just send 1.

This is true, but I don’t see it as relevant. One of the points of having separate withdrawal and validation accounts is that it allows separation of trust. The situation where a user trusts a third party to run a validator on their behalf but not with their funds is a valid one, so should be addressed.

1 Like