[Bug] Malicious validator attack disrupts consensus by blocking certificate request
feezybabee opened this issue · comments
https://hackerone.com/reports/2485380
Summary:
Malicious validator send invalid BatchPropose
and block the CertificateRequest
Steps To Reproduce:
git clone git@github.com:ghostant-1017/mysnarkOS.git && git checkout attack/blocking-certificate-request
- Start the devnet
cd snarkos && ./devnet
with 4 validators, 0 clients - Observe the logs of
validator1
Proof-of-Concept (PoC)
-
Assume validator0 is a malicious node, and validator1 is the node under attack.
-
The main approach of this attack is that validator0 frequently sends
BatchPropose
to validator1, whereprevious_certificate_ids
will includeBatchCertificateID
of other honest nodes. However, validator0 does not respond to validator1'sEvent::CertificateRequest
requests. When validator1 receives requests from honest nodes, due to the limitation on sending CertificateRequest, it will not send requests to other nodes. This eventually leads to validator1 being unable to communicate with other honest nodes. -
This attack can prevent honest nodes from participating effectively in the consensus process, thereby affecting block production.
Supporting Material/References:
Logs:
2024-05-01T16:26:11.132940Z DEBUG Skipped sending request for certificate 7525999521597754.. to '127.0.0.1:5003' (2 redundant requests)2024-05-01T16:26:11.132940Z DEBUG Skipped sending request for certificate 7525999521597754.. to '127.0.0.1:5003' (2 redundant requests)
Additionally:
2024-05-01T16:17:34.709477Z ERROR Unable to advance to the next block - Failed to speculate on transactions - Failed to post-ratify - Next round 738 must be greater than current round 738 2024-05-01T16:17:34.709539Z ERROR BFT failed to advance the subdag for round 738 - Failed to speculate on transactions - Failed to post-ratify - Next round 738 must be greater than current round 738
the cause of this issue has not been identified yet
Impact
This attack can prevent honest nodes from participating effectively in the consensus process, thereby affecting block production.
Thank you for this report! We'll checkout your example and attempt to verify it.
Confirmed that this is an issue that can be mitigated in a multitude of ways:
- Rate limit batch propose messages from peers
- Bound the sent_requests to peers. i.e. send 1 request to a peer at a time
I would say it's of high severity as it is a DOS attack that can be pretty easily mitigated. It also isn't a guarantee'd attack (although it can be sustained).
@ghostant-1017 I have a proposed solution here - #3257. Let us know if this addresses the issue you highlighted!
As usual, thank you for your diligence in finding and bringing these bugs to our attention.
Closing with #3257