Re: Proposed release of the Iroha audit report


Mark Wagner
 

Sounds like we a blockchain based voting app for the TSC. Is there a new lab in our future?


On Wed, Jan 2, 2019, 09:49 David Huseby <dhuseby@...> wrote:
By my count I've got yes votes from:
Mark, Arnoud, Hart, Baohua, Dan and Nathan

I'm waiting on:
Binh, Chris, Kelly, Mic, and Silas

Thanks,
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation
+1-206-234-2392
dhuseby@...

On Wed, Jan 2, 2019 at 5:19 AM David Huseby <dhuseby@...> wrote:
>
> So is it officially approved?
>
> Dave
>
> On Fri, Dec 21, 2018 at 8:41 AM Dan Middleton <dan.hyperledger@...> wrote:
>>
>> +1
>>
>> On Fri, Dec 14, 2018 at 2:26 PM Baohua Yang <yangbaohua@...> wrote:
>>>
>>> LGTM!
>>> Thanks!
>>>
>>> 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.
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Hart
>>>>
>>>>
>>>>
>>>> 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...
>>>>
>>>>
>>>>
>>>> -mark
>>>>
>>>>
>>>>
>>>> On Tue, Dec 11, 2018 at 8:44 AM Arnaud Le Hors <lehors@...> wrote:
>>>>
>>>> SGTM.
>>>> --
>>>> 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 ?
>>>> -mark
>>>>
>>>> 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 (
>>>> 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.
>>>>
>>>> Cheers!
>>>> Dave
>>>>
>>>>
>>>>
>>>> ---
>>>> David Huseby
>>>> Security Maven, Hyperledger
>>>> The Linux Foundation
>>>> +1-206-234-2392
>>>> dhuseby@...
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>
> --
> ---
> David Huseby
> Security Maven, Hyperledger
> The Linux Foundation
> +1-206-234-2392
> dhuseby@...



Join toc@lists.hyperledger.org to automatically receive all group messages.