RocketPool and Lido are both third party staking pools for Ethereum 2.0. Proof of stake, vs. proof of work, is the future, as it should make the Ethereum much more performant. Instead of random people computing a hash, a staker will propose and validate blocks from other validators. A person is only a staker if they have deposited funds into the staker contract themselves.
Currently, to be a staker in Ethereum 2.0, it is 32ETH or around 112K. Because this is so expensive, staking pools were created. The purpose of this is to pool together user funds to become a staker as a group. Then, from staking, you get rewards for doing so.
When an Ethereum transaction is made, it isn't made instantaneously. Instead, it is stuck into a queue of our transactions. The validators will choose which transactions to put into the next block, depending on the amount paid to perform the transaction. So, what would happen if somebody abused their knowledge of the queue to do something malicious? This is called frontrunning.
The deposit contract is used for sending the money to be a validator. This takes in three main parameters: BLS public key for validator, withdrawal credentials and signature of the data above.
This is how a user signs up for the service. When value is added to deposit for a NEW user, the user is created within an IF statement. However, if the user, which is defined by the public key is already in the system, the funds are simply added to that validator.
An attacker can SEE the presence of a deposit using a specific public key. Once they see this, they can create their own transaction linking their account to this public key PRIOR to the original user. Once the original users transaction goes through, the funds will be added to the attacker account, because of the else clause, instead of being in the new users account. Damn, that's crazy!
Frontrunning appears to be more of a problem within the cryptocurrency bot community. However, it does have serious consequences in the security world as well. In this case, the identification of a user was NOT their address; instead, a value that could be spoofed. Interesting bug that the developers explain well
here as well.
It should be noted that this required a node operator to go rogue to perform this attack; this is considered a privileged user nonetheless but still got a 100K bounty for each project this effected. The authors include a few possible mitigations as well.