Investigate potential vulnerability in ChainMuxer (preventing Follow Mode)

[LesnyRumcajs]

Issue summary

As per @aakoshh thread (thank you!) in #fil-forest-dev Slack, this should be investigated further as part of hardening Forest and we should assess the severity and potential solutions.

When the node starts, the ChainMuxer is in the Idle state and will start with the evaluate_network_head step. That will wait until it receives tipset_sample_size P2P messages which contain some tipset (HelloMessage or PubsubMessage of a block do), then it will select the header with the highest weight. While it's gathering the sample it does some validation but it can't do much without the history, it only checks if the message root CID is correct (NB also stores the arrays it in the database even if the header has a different CID), that the epoch compares reasonably to the wall clock time based on the expected block delay (it allows a drift of maximum 5 epochs), and that the block isn't already in the bad_block_cache. I don't know why it doesn't check signatures here, but it wouldn't make a difference for my question if it did.Once it has the candidate for the network head, it goes into bootstrap mode to request the blocks between its head and the network. That will try to download the headers in reverse, then execute blocks going forward. If it cannot connect then at some point the block will be added to the bad_block_cache , and the muxer goes back to Idle , and then will start again from the evaluation of the network head.Now, for the attack: what if an adversary always says it has a tipset with 5 epochs higher than its real head? It will always be picked as the best network head, and then it looks like it can always fabricate a history of headers until it hits the fork threshold. At that point the node will give up following this line of headers, but it doesn't look like the peer is ever put on a blacklist for this.The TL;DR is that it looks to me like a single malicious peer can sort of eclipse a node by always taking it down a garden path with the promise of a heavier chain to nowhere, preventing it from ever entering Follow mode where it would accept messages from others.cc

EDIT: I see one protection is that it doesn't ask that specific peer for the history, but because it asks all of them, eventually it will ask the adversary as well (as long as it stays in the top 16 peers). Maybe another reason the attack wouldn't work is if the P2P messages are constantly coming from all over and buffered, so the adversary would have to send a lot of gossip to make sure it's always present in any sample of 5 messages (the default tipset_sample_size). (edited)

Other information and links