[Bug] Malicious validator attack disrupts consensus by blocking certificate request

[feezybabee]

https://hackerone.com/reports/2485380

Summary:

Malicious validator send invalid BatchPropose and block the CertificateRequest

Steps To Reproduce:

1. git clone git@github.com:ghostant-1017/mysnarkOS.git && git checkout attack/blocking-certificate-request
2. Start the devnet cd snarkos && ./devnet with 4 validators, 0 clients
3. Observe the logs of validator1

Proof-of-Concept (PoC)

1. Assume validator0 is a malicious node, and validator1 is the node under attack.

2. The main approach of this attack is that validator0 frequently sends BatchPropose to validator1, where previous_certificate_ids will include BatchCertificateID of other honest nodes. However, validator0 does not respond to validator1's Event::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.

3. 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.

[iamalwaysuncomfortable]

Thank you for this report! We'll checkout your example and attempt to verify it.

[raychu86]

Confirmed that this is an issue that can be mitigated in a multitude of ways:

1. Rate limit batch propose messages from peers
2. 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).

[raychu86]

@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.

[ghostant-1017]

@raychu86 Yes, I think the solution can mitigate this attack.