Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

replay attack on batcher disrupts a particular user #1081

Closed
entropidelic opened this issue Sep 25, 2024 · 0 comments
Closed

replay attack on batcher disrupts a particular user #1081

entropidelic opened this issue Sep 25, 2024 · 0 comments

Comments

@entropidelic
Copy link
Contributor

entropidelic commented Sep 25, 2024

Problem

In the Batcher, in handle_message, a ClientMessage is received, the signature is checked (but the nonce is not checked yet), then the proof count is checked and incremented for that user.

The proof count is used to estimate whether the user has enough Ethereum balance to pay for the proof. The proof count is not reset until after the batch is submitted, so any subsequent proof requests within this batch will have an incremented proof count

The proof is then validated, and finally, the nonce is checked and incremented. If the ClientMessage was replayed, the proof will be valid but the nonce will not be.
Consequently, the message will be dropped and will not be included in the batch.

However, because the proof count is still incremented, it will appear as though the user needs more balance to pay for the next proof that they submit. If an attacker submits many replays, they can eventually increase the cost estimate, such that a real proof will not be accepted.

An Aligned Layer user is expected to have a minimum balance per proof of 13,000*100 gwei = 0.0013 Ether, which, as of the writing of this report, is equivalent to 3.36 USD. Hence, if the attacker is able to submit 30 invalid proofs (increasing the proof count to 30), the Batcher will then require the user to have more than 100 USD in their balance.
Moreover, since the balance for a user is public information, the attacker can check how many invalid proofs need to be replayed.

Remediation

Check the nonce at the start when checking the signature but refraining from incrementing it until the end, once the ClientMessage is fully validated.

Additional Remediation Considerations (Mauro)

Just checking the nonces without locking the whole state will lead to race conditions. Locking the whole state is also problematic, since it will make the whole batcher work sequentially. We need to move the UserState away from the BatchQueue, and have locks per user, to allow concurrency and avoid. this race condition

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

3 participants