Re: Proposed release of the Iroha audit report

Dan Hyperledger


On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:

On Fri, Dec 14, 2018 at 3:41 PM hmontgomery@... <hmontgomery@...> wrote:

Yeah, I’m pretty much always in favor of releasing security audits if the bugs have been fixed.





From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Friday, December 14, 2018 5:30 AM
To: Arnaud Le Hors <lehors@...>
Cc: dhuseby@...; hyperledger-tsc <hyperledger-tsc@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Proposed release of the Iroha audit report


Does anyone else on the TSC have an opinion on this ?


If we want to streamline TSC calls and do online voting, we actually need to pay attention to the emails...




On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:

Arnaud  Le Hors - Senior Technical Staff Member, Web & Blockchain Open Technologies - IBM

From:        "mark wagner" <mwagner@...>
To:        dhuseby@...
Cc:        hyperledger-tsc <hyperledger-tsc@...>
Date:        12/06/2018 07:39 PM
Subject:        Re: [Hyperledger TSC] Proposed release of the Iroha audit report
Sent by:        tsc@...

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@...> wrote:
Hello TSC,

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 (  All four issues were
tracked using our JIRA and resolved earlier this year.

Memory leak in Irohad (
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 (
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 (
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 (
This was a small error that is resolved by using DNS names and is not
really a problem to hold up the release.


David Huseby
Security Maven, Hyperledger
The Linux Foundation

Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc

Best wishes!

Baohua Yang

Join to automatically receive all group messages.