You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
The text was updated successfully, but these errors were encountered: