Re: Proposed release of the Iroha audit report
toggle quoted messageShow quoted text
Thanks for the great writeup Dave
As you mentioned that all four issues have been resolved I would currently vote to release the report. <insert weasel words here> Of course if others come up with an objection that I had not considered I may need to factor that into my decision. </weasel words>
What do others think ?
On Thu, Dec 6, 2018 at 8:56 AM David Huseby <dhuseby@...
As part of my visit to the Iroha team, I finalized the Iroha audit
checks with the team and I think that it is time to publish the Iroha
audit report and I would like the TSC's approval to do so. I
recommend that the report be published.
The Iroha audit found four security issues, including one that was
critical enough to require us to issue our first CVE (
https://www.cvedetails.com/cve/CVE-2018-3756/ ) All four issues were
tracked using our JIRA and resolved earlier this year.
Memory leak in Irohad ( https://jira.hyperledger.org/browse/IR-1 )
Nettitude found a memory leak associated with processing a remote
request that creates a very slow potential denial of service.
Multi-signatory transactions can potentially be authorised by single
user ( https://jira.hyperledger.org/browse/IR-2 )
This bug exploited some errors in the signature storage and validation
to bypass the transaction signature validation. This is similar to
bug #3 bellow. A malicious user could bypass the transaction
signature checking by signing it multiple times with a
non-deterministic signature scheme.
Vote early, Vote often ( https://jira.hyperledger.org/browse/IR-3 )
This is the issue that required a CVE. Nettitude found that by
modifying the ed25519 signature library to use random nonces instead
of message hashes, the signature checking code could be exploited to
accept multiple signatures produced with the same keypair. This
allowed a single malicious node to sign the malicious transaction
multiple times and the other nodes would view the signatures as unique
and valid. This completely bypasses one part of the byzantine fault
tolerance of the blockchain.
IP addresses can be made permanently unusable using the add peer
command ( https://jira.hyperledger.org/browse/IR-4 )
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.
Security Maven, Hyperledger
The Linux Foundation
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc
Join email@example.com to automatically receive all group messages.