Zebra Pre-Auth DoS via Quadratic Complexity in Block Contextual Verification (CVE-like)

Vulnerability Overview Vulnerability Name: Quadratic transparent value check in block contextual verification Severity: Moderate (5.9 / 10) CVSS 3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H CWE: CWE-407 (Inefficient Algorithmic Complexity) / CWE-405 (Asymmetric Resource Consumption) Affected Versions: 6.0.0 Fixed Versions: 6.1.0 Reporter: @ebfull and @ValarDragon Fixing PR: #10995 Description When Zebra verifies blocks during contextual verification, it checks the remaining transparent value of each non-coinbase transaction. The current implementation clones and transforms the entire block-level spent-UTXO map once per transaction (twice, in fact, because the value-balance transformation clones it again), rather than only propagating the outputs spent by each transaction. For transactions near the 2,000,000-byte limit that pack in minimal single-input transactions, this converts a linear-time value check into quadratic hash map allocation and copying, measuring over 52 seconds to process a single block. Since the affected code only runs after proof-of-work and other semantic checks pass, triggering it requires generating a valid blind block, which limits who can cause it and the cost. Impact Scope Availability: High Attack Vector: Network Attack Complexity: High Privileges Required: None User Interaction: None Scope: Unchanged Confidentiality: None Integrity: None Availability: High Remediation 6.1.0: The fix ensures that only the outputs spent by each transaction are propagated, rather than cloning the entire block-level map per transaction. - In , a per-transaction view containing only the transaction's spent outpoints is constructed or borrowed, and passed to , making the per-transaction cost proportional to the number of inputs in the transaction. - Additionally, a second clone is avoided by using instead of cloning and transforming (transaction.rs:1565). Patch Code Workarounds There are no configuration-only workarounds; the check runs on the standard block verification path. The proof-of-work requirement limits the attack (non-blind blocks cannot reach the chain), but does not prevent it, as a worst-case block can be directly mined or injected into the mempool for honest miners to mine, and ZIP-317 fees do not block it. The patch is persistent after upgrading. Impact Impact is limited to availability only. An actor can construct a worst-case block, either by direct mining or by injecting it into the public mempool with minimal transparent transactions for honest miners to mine, causing each validating node to spend over 52 seconds processing the block. The effect is clear upon process completion. It does not amplify attacks on new blocks, nor does it crash nodes, cause consensus divergence, or corrupt state. Severity depends on whether the process stall blocks the rest of the block processing (missing timers, dropping gossip, sync lag) or its duration/isolation of block processing, which awaits confirmation. Triggering still requires a valid proof-of-work block to exist; mempool injection lowers the attacker's cost (fees rather than hash power) for a few ZEC and opportunistic miner behavior, but does not change fees, and ZIP-317 fees do not block it. The limited, one-off, self-cleaning nature of the stall keeps realistic incentives low. References zebra-state/src/service/check/utxo.rs:38, 84, 143, 231, 244 (transparent_spend, remaining_transaction_value, utxos_from_ordered_utxos, the per-transaction clone) zebra-chain/src/transaction.rs:1561, 1565 (value_balance, the second clone) zebra-consensus/src/block.rs:241, 248, 247, 257, 394 (proof-of-work and merkle checks before the state commit) CWE-407, CWE-405

Goal Reached Thanks to every supporter — we hit 100%!

Zebra Pre-Auth DoS via Quadratic Complexity in Block Contextual Verification (CVE-like)

More from this source