From d494af1e90a9569ce23366f614eb8327a4e84fae Mon Sep 17 00:00:00 2001 From: teor Date: Thu, 11 Mar 2021 11:29:21 +1000 Subject: [PATCH] Document how the syncer resists memory DoS --- zebrad/src/components/sync.rs | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/zebrad/src/components/sync.rs b/zebrad/src/components/sync.rs index 0392cef67..159e9e8d2 100644 --- a/zebrad/src/components/sync.rs +++ b/zebrad/src/components/sync.rs @@ -40,6 +40,21 @@ const BLOCK_DOWNLOAD_RETRY_LIMIT: usize = 2; /// /// Set to two checkpoint intervals, so that we're sure that the lookahead /// limit always contains at least one complete checkpoint. +/// +/// ## Security +/// +/// If a malicious node is chosen for an ObtainTips or ExtendTips request, it can +/// provide up to 500 malicious block hashes. These block hashes will be +/// distributed across all available peers. Assuming there are around 50 connected +/// peers, the malicious node will receive approximately 10 of those block requests. +/// +/// Malicious deserialized blocks can take up a large amount of RAM, see +/// [`super::inbound::downloads::MAX_INBOUND_CONCURRENCY`] and #1880 for details. +/// So we want to keep the lookahead limit reasonably small. +/// +/// Once these malicious blocks start failing validation, the syncer will cancel all +/// the pending download and verify tasks, drop all the blocks, and start a new +/// ObtainTips with a new set of peers. const MIN_LOOKAHEAD_LIMIT: usize = zebra_consensus::MAX_CHECKPOINT_HEIGHT_GAP * 2; /// Controls how long we wait for a tips response to return.