The registerBLSPublicKeys in LiquidStakingManager.sol is vulnerable to frontrunning.

[code423n4]

Lines of code

https://github.com/code-423n4/2022-11-stakehouse/blob/4b6828e9c807f2f7c569e6d721ca1289f7cf7112/contracts/liquid-staking/LiquidStakingManager.sol#L426

Vulnerability details

Impact

The registerBLSPublicKeys and deposit function in StakingFundsVault.sol and in SavETHVault.sol is vulnerable to frontrunning.

Proof of Concept

When user register a ETH 2.0 public key as the node operator, he needs to call the function register in LiquidStakingManager.sol

/// @notice register a node runner to LSD by creating a new smart wallet
/// @param _blsPublicKeys list of BLS public keys
/// @param _blsSignatures list of BLS signatures
/// @param _eoaRepresentative EOA representative of wallet
function registerBLSPublicKeys(
    bytes[] calldata _blsPublicKeys,
    bytes[] calldata _blsSignatures,
    address _eoaRepresentative
) external payable nonReentrant {

the blsSignature is used for ETH 2.0 staking related validation:

https://kb.beaconcha.in/ethereum-2-keys#ethereum-2-keys

However, this function is vulnerable to front-running.

Consider this case:

1. User A get a public key and the corresponding signature.
2. User A wants to use the key pair to register the node operator and assign a eoaRepresentive.
3. User A is a average crypto user that does not know flashbot and know the concept of front-running.
4. User A submit transaction using a normal RPC and the transaction goes to mempool.
5. User B a front-running bot decode the transcation and see the public key and the signature.
6. User B front-run user A by using the same public key and the signature to appoint a different eoaRepresentative.
7. User B optimizes the transaction such as bribe the miner or paying higher priority fee.
8. The public key and the signature is used by user B, User A find his transaction reverted.

Tools Used

Code inspection.

Recommended Mitigation Steps

Let the msg.sender of the registerBLSPublicKeys can submit a signature (generated using msg.sender address and the public key and eoaRepresentative across) along with the transaction to prove that the eoaRepresentative and the public key is used correctly.

[c4-judge]

dmvt marked the issue as primary issue

[c4-sponsor]

vince0656 marked the issue as sponsor disputed

[vince0656]

Not sure what someone gains by doing this. In order for their front run transaction to go through, they have to use 4 of their own ETH and they will not have the correct signing key to proceed which is a differnet issue beacuse then people would waste time staking for a BLS key that can never be staked. It is possible to filter BLS keys that have invalid node runner registrations.

[dmvt]

Yeah I didn't fully appreciate that on the first pass. Given how expensive this griefing attack would be to execute, and the relatively low impact, I don't think this is a real issue.

[c4-judge]

dmvt marked the issue as nullified