Deposit contract exploit

Proof-of-Stake
1

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.

8 Likes
2

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
3

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
4

Is this issue still present in the current deposit contract?

5

This is a known quantity to spec writers, but could maybe use some better public information.

@jgm put this up for discussion last December and we showed in that issue that there is a safe protocol for key exchange. See initial conversation – https://github.com/ethereum/eth2.0-specs/pull/1506#issuecomment-564086671

We also discussed potential modifications to the deposit contract, but all of these, imo, led to a more complicated and/or confusing scenario for stakers. I’m not currently where all of these various threads of conversation are.

Key exchange protocol copied here for discussion

So you can actually avoid front-running without passing the full private key without making changes to the deposit contract.

  • Sally the staker has a BLS private and public key
  • Derrick the delegate has a BLS private and public key
  • Derrick sends his public key to Sally. Sally combines it with her public key to create the public signing key for the validator.
  • Sally sends the deposit data D (including the combined key) to Derrick.
  • Derrick signs D with his half of the key and sends it back to Sally
  • Sally signs D and creates an aggregate of the signature that can be verified by the combined key.
  • Sally sends D along with the 32 eth to the deposit contract
  • After successful confirmation in the deposit contract, Sally sends her half of the private key to Derrick to do active validation

Only half of the private key was every transmit on the wire, so exposure of the full key to a monitoring attacker is not a risk

6

An example of this type of exploit was reported in Lido Finance’s whitelisted Node Operator contract, read more here: https://blog.lido.fi/vulnerability-response-update/

1 Like