zakura

Release: Zakura 1.0.1

We have released Zakura 1.0.1, a security release. It fixes three issues that our team discovered in upstream Zebra and that affect Zakura 1.0.0. We recommend that all node operators update immediately.

Security fixes

This release includes the following fixes. All three issues are denial-of-service vectors: an attacker could degrade or stall a node's block validation or mining. Our teams consider these kinds of issues high severity for miners. But none of them can lead to loss of user funds, crashes, state corruption, or consensus divergence.

  • Quadratic block processing time (GHSA-4g24-549m-hp75). Transparent transactions in blocks were verified with an algorithm whose running time grows quadratically, which an adversary could exploit to stall block validation without mining a malicious block themselves. In our measurements, the stall could last nearly 52 seconds on fast hardware.
  • Remote validation poisoning (GHSA-g7c4-2w6c-cr3r). Nodes did not track which peers sent them transactions that violate consensus rules, including transactions with invalid proofs. Orchard proofs, for example, are verified in batches, and proofs from all sources feed into a shared verification pipeline; a malicious peer could therefore poison batches with invalid proofs without being identified or penalized. A failed batch forces block processing onto an expensive fallback path, allowing sustained degradation of a node's block validation performance, on the order of tens of seconds.
  • Oversized block templates (GHSA-95m2-vx53-v2jw). The getblocktemplate RPC could produce block templates that violated the allowed block size, because parts of the serialized block, such as the header, were not counted toward it. An adversary could provoke this deliberately to stall mining on a targeted node, for example one producing blocks for a mining pool.

Coordinated disclosure

Our team discovered these issues in Zebra prior to the initial release of Zakura, which inherited them. We performed our 1.0.0 release as planned and began coordinated disclosure with the Zcash Foundation immediately afterward. Zebra fixes these issues in version 6.1.0.

We thank the Zcash Foundation for responding promptly and coordinating these fixes with our team.

Our team also privately disclosed these vulnerabilities to Shielded Labs at the same time. However, due to time constraints and differing priorities, they are not part of this coordinated software release.

End-of-support halt

Anticipating that these issues would need to be remediated immediately after launch, we shipped 1.0.0 with its EOS halt set just one week after release. 1.0.0 nodes will begin warning about the required update within days and will halt shortly afterward. Zakura 1.0.1 reaches end of support roughly one week after Ironwood (NU6.3) activates.

Other improvements

This release also contains performance and stability improvements:

  • Initial sync now runs in bounded memory. During initial sync, blocks download faster than they can be verified, and the backlog was held as fully decoded blocks, which are several times larger than their wire encoding. Memory use therefore grew with the chain itself. The backlog is now kept in serialized form and decoded only as blocks enter verification, which turns the sync look-ahead budget (1.5 GiB by default) into a real memory bound. Memory use is also tracked through the sync pipeline and exported as metrics, so a syncing node's memory behavior can be watched on a dashboard rather than inferred from RSS.
  • Fewer ways for initial sync to stall. Header ranges that time out are now retried indefinitely, briefly avoiding the peers that failed them, and bookkeeping at checkpoint boundaries no longer leaves verification capacity sitting idle. Heights whose blocks add no Sapling commitments are no longer mistaken for gaps in sync coverage, and pruned nodes (which have dropped old block bodies) no longer invent metadata for blocks they no longer store.
  • Stricter with untrusted bytes. ZIP-244 transaction IDs, and therefore the block hash, don't commit to signatures, proofs, or transparent unlocking scripts, so a block body with the correct hash can still carry altered authorizing data. Block bodies from cache or from peers are now also checked against the authorizing-data root, and a body with the right hash but the wrong authorizing data is rejected as permanently invalid instead of retried. Oversized FindBlocks responses from legacy peers are rejected before they touch state lookups, and invalidating a block now removes every fork built on it, not just one of them.

Updating

You can update using our signed release binaries or by upgrading the zakura crate to 1.0.1 via Cargo. See the download page for installation and verification instructions.