The Horizen team is committed to the security and safety of our users as we aim to develop the most secure, interoperable blockchain ecosystem.
In January 2020, Horizen issued a request for a quote to several audit companies with blockchain and cryptography experience. Through our contracts selection process, the contract was awarded to Coinspect due to their industry experience in auditing Bitcoin security services and their in-depth familiarity with the Zcash codebase from previous audits.
The objective of the audit was to identify security vulnerabilities: full system compromise, denial of service attacks, information disclosure, network protocol weaknesses, input validation, and misaligned incentives in consensus rules. Third-party audits are an unbiased mechanism to assess the security of a system yet cannot guarantee the full safety of the network.
The audit focused on reviewing the Horizen platform additions to the Zcash protocol implementation including its core consensus rules, network protocols, and privacy features. In addition, Coinspect verified Horizen properly fixed every known vulnerability inherited from Zcash upstream.
Coinspect found no high-risk vulnerabilities introduced by Horizen’s modifications to the Zcash source code. The audit findings included 7 risk items; 6 of 7 issues were fixed and released to production. The remaining open item is of low severity. Horizen mitigated the open issue by expanding the documentation. Finding summary is listed below:
- Critical Risk: 0
- High Risk: 1 (1 fixed)
- ZEN-006 – Consensus fork and double-spend attack risks because of unpatched Zcash CVE-2020-8806, fixed with ZEN 2.0.21
- Medium Risk: 4 (4 fixed)
- ZEN-002 – Incongruent parsing of OP_CHECKBLOCKATHEIGHT parameters leads to the creation of unspendable UTXOs, fixed with ZEN 2.0.22
- ZEN-003 – Incoherent and lax parsing of OP_CHECKBLOCKATHEIGHT parameters – not started, to be evaluated and scheduled, fixed with ZEN 2.0.22
- ZEN-004 – DoS: OP_CHECKBLOCKATHEIGHT verification performed after CPU intensive signature verifications, fixed with ZEN 2.0.22
- ZEN-007 – The TLS implementation supports version 1.0 of the TLS protocol. This version of the TLS protocol suffers from multiple well-known cryptographic flaws and is widely considered insecure by industry-standard best practices, fixed with ZEN 2.0.22
- Low Risk: 2 (1 fixed; 1 remains open)
- ZEN-001 – Secure connection downgrade and lack of TLS peer certificate validation by default. Horizen decided to not fix this finding because doing so would break backward compatibility with other components in their ecosystem. However, mitigation measures were taken: documentation was improved regarding certificate validation, and a command-line option to disable the unencrypted connection fallback was added.
- ZEN-005 – Unused and incorrect function in delay.cpp, fixed with ZEN 2.0.22