Date   

Re: Getting error while running node enrollAdmin.js

Chris Gabriel <alaskadd@...>
 

Hi Sudan,
Step 1: In package.json file, ensure node version is correct.
Step 2: Delete package-lock.json (make sure you delete package-lock.json and NOT package.json)
Step 3: Delete the node_modules folder
Step 4: Run mom install again

Be sure to report your result back to this list so others can learn. 
Thanks,
Chris


On Mar 31, 2021, at 5:30 AM, Sudhan Manoharan <sudhanmanoharan@...> wrote:


Hi Nidhi,
    I tried with node v12.0.0 and npm 6.9.0. But the same issue.

<Screenshot 2021-03-31 at 4.58.34 PM.png>


Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:48 PM Nidhi Singh <nidhi2894@...> wrote:
Sudhan,

As per the documentation, Fabric Node SDK supports Node.js version 10 from 10.15.3 and higher. 

Your current version 10 is lower than this. Can you try upgrading node and running npm install. 


Thanks,
Nidhi


On Wed, Mar 31, 2021, 4:36 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi arthur,
   Thanks for ur response. Getting the same issue after with ur command.

Thanks & Regards,
Sudhan

On Wed, Mar 31, 2021 at 4:30 PM Arthur Souza <arthur.msouza@...> wrote:
Hi Nidhi,

please try to type the following command:

npm install --unsafe-perm=true --allow-root

Arthur 

On Wednesday, March 31, 2021, Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

<Screenshot 2021-03-31 at 3.46.03 PM.png>


Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Sudhan Manoharan
 

Hi Nidhi,
    I tried with node v12.0.0 and npm 6.9.0. But the same issue.

Screenshot 2021-03-31 at 4.58.34 PM.png

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:48 PM Nidhi Singh <nidhi2894@...> wrote:
Sudhan,

As per the documentation, Fabric Node SDK supports Node.js version 10 from 10.15.3 and higher. 

Your current version 10 is lower than this. Can you try upgrading node and running npm install. 


Thanks,
Nidhi


On Wed, Mar 31, 2021, 4:36 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi arthur,
   Thanks for ur response. Getting the same issue after with ur command.

Thanks & Regards,
Sudhan

On Wed, Mar 31, 2021 at 4:30 PM Arthur Souza <arthur.msouza@...> wrote:
Hi Nidhi,

please try to type the following command:

npm install --unsafe-perm=true --allow-root

Arthur 

On Wednesday, March 31, 2021, Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Nidhi Singh
 

Sudhan,

As per the documentation, Fabric Node SDK supports Node.js version 10 from 10.15.3 and higher. 

Your current version 10 is lower than this. Can you try upgrading node and running npm install. 


Thanks,
Nidhi


On Wed, Mar 31, 2021, 4:36 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi arthur,
   Thanks for ur response. Getting the same issue after with ur command.

Thanks & Regards,
Sudhan

On Wed, Mar 31, 2021 at 4:30 PM Arthur Souza <arthur.msouza@...> wrote:
Hi Nidhi,

please try to type the following command:

npm install --unsafe-perm=true --allow-root

Arthur 

On Wednesday, March 31, 2021, Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Sudhan Manoharan
 

Hi arthur,
   Thanks for ur response. Getting the same issue after with ur command.

Thanks & Regards,
Sudhan

On Wed, Mar 31, 2021 at 4:30 PM Arthur Souza <arthur.msouza@...> wrote:
Hi Nidhi,

please try to type the following command:

npm install --unsafe-perm=true --allow-root

Arthur 

On Wednesday, March 31, 2021, Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Sudhan Manoharan
 

What result does pkcs11js installation gave?

Screenshot 2021-03-31 at 4.34.02 PM.png
Which version of fabric are you using?
  Fabric v2.2  
And you are trying this on which OS?
 macOS catalina 


On Wed, Mar 31, 2021 at 4:27 PM Nidhi Singh <nidhi2894@...> wrote:
Sudhan,

What result does pkcs11js installation gave?

Which version of fabric are you using ? And you are trying this on which OS ?

Thanks,
Nidhi Singh


On Wed, Mar 31, 2021, 4:12 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Arthur Souza
 

Hi Nidhi,

please try to type the following command:

npm install --unsafe-perm=true --allow-root

Arthur 


On Wednesday, March 31, 2021, Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Nidhi Singh
 

Sudhan,

What result does pkcs11js installation gave?

Which version of fabric are you using ? And you are trying this on which OS ?

Thanks,
Nidhi Singh


On Wed, Mar 31, 2021, 4:12 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Sudhan Manoharan
 

Hi Nidhi,
    Thanks for ur reply. I can't find the 'pkcs11js' library inside the node_module folder. I did a manual installation of pkcs11js library that also not help me. Same error and I'm also in the correct directory.
Addition information
Node: 10.14.1
NPM: 6.4.1

Thanks,
Sudhan

On Wed, Mar 31, 2021 at 4:02 PM Nidhi Singh <nidhi2894@...> wrote:
Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Nidhi Singh
 

Hi Sudhan,

Can you verify node_modules is installed for this 'pkcs11js'.

Inside node_modules are you able to see this module ?

Or run npm install in the correct directory having the package.json file and try again.

Thanks,
Nidhi


On Wed, Mar 31, 2021, 3:49 PM Sudhan Manoharan <sudhanmanoharan@...> wrote:
Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Re: Getting error while running node enrollAdmin.js

Sudhan Manoharan
 

Hi Team,
     I'm trying to write chaincode and invoking chaincode by using node js SDK. But I'm facing one issue. While trying to run the node enrollAdmin.js to enroll the user in the blockchain network. But during this process, I'm facing an issue like Error: Cannot find module 'pkcs11js' [ I attached the detailed image in the following mail ].  Please help me out to resolve this issue. 

Screenshot 2021-03-31 at 3.46.03 PM.png

Thanks,
Sudhan


Is there any way to query the couchDB records by nested properties of an array? #couchdb #fabric-chaincode

Marek Malik <info@...>
 

Hi there, 

I'm was trying to find out if this is possible on the SO and reading the CouchDB documentation, but could not find anything that would work on the Fauxton web client to test it.

I have a data structure that aggregates into an array of items. There is this one use case where I need to query for all objects that have any of its items containing a given value. I was hoping to make the data structure not flat because of the quickness of retrieving the data by the key which is the main use case. But I need to have the second use case, and I don't know how many items there would be so this feature could eventually end up running long.
Is there any way I can utilize CouchDB to work in my favor or I need to flatten the data structure?

Thanks for any help

Marek


Re: Security Analysis of Private Data Collection of Hyperledger Fabric

Baohua Yang
 

I think senthil made a good point here.

Setting the default policies to a more restricted value (e..g, "memberOnlyRead/Write=true") will help reduce the anxiety.

This reminds me of the well-known mongoDB issue, when tens of thousands of mongoDB instances leaked the data due to a not very secure default configuration. 

Although the mongoDB team blamed that the users did not follow the guideline quite well, it's glad to see that mongoDB choose a more secure default configuration in its newer releases.

We should not consider the issue as a big vulnerability, and it's always challenging to have a perfect design with both security and configurability.

On Tue, Mar 30, 2021 at 10:08 AM Senthil Nathan <cendhu@...> wrote:
These are neither design flaws nor vulnerabilities. We have various configuration parameters for private data collection. For example, the following is a configuration of a private data collection.
 {
    "name": "collectionMarblePrivateDetails",
    "policy": "OR('Org1MSP.member')",
    "requiredPeerCount": 0,
    "maxPeerCount": 3,
    "blockToLive":3,
    "memberOnlyRead": true,
    "memberOnlyWrite": true,
    "endorsementPolicy": {
      "signaturePolicy": "OR('Org1MSP.member')"
    }
 }

Depending on the use-case, one can set the memberOnlyRead and memberOnlyWrite to false. As a result,
a non-member can read and write to a collection. If an use-case wants a very restrictive access to the private
data collection, these parameters must be set to true. I don't think we can call this a design flaw. This is by
design and the documentation explains these configuration in details
(https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data-arch.html)
Similarly, the endorsement policy can be set at the collection level as seen in the above configuration. It can also be at the key-level for more fine-grained control. Again, these are configuration parameters for the collection and the use-case dictates the required configuration.

I can go on but there are no design flaws or vulnerability in the Private Data Collection.

If the application/use-case does not configure the private data collection as per the need/requirement, it is not the fault of Hyperledger Fabric. For example, one must configure the firewall correctly in the production network. Without doing that, we cannot claim the networking stack in Linux Kernel to have vulnerabilities that allow unrestricted access.

I agree with Dave that the paper needs to be revised to say how to configure private data collections for various use-cases and requirements. 

Regards,
Senthil

On Tue, Mar 30, 2021 at 10:01 PM Todd Little <toddjlittle@...> wrote:
As it appears the "issues" described in this paper are not really security issues, can the paper be made available to a wider audience?  Hackerone has all the reports related to this marked as private and inaccessible. Or can the reports be made public?

Regards,
Todd

On 3/29/2021 9:28 AM, David Enyeart wrote:

I still think it is in your best interest to make some minor updates to the paper content to avoid using sensational language such as "design flaws" and "vulnerabilities". Researchers tend to get discredited when their assertions get shown to be misleading or untrue. The original sponsor for the private data feature specifically requested the existing chaincode-level endorsement policy design for their use cases, and the more constrained collection-level endorsement policies were added as a parallel approach for other use cases. Calling out the original broadly as a design flaw is misleading and untrue when you consider the sponsor use case or review the Fabric documentation.

I would very much support moving forward with the paper if it were recast as guidance for securing private data collections under various use case considerations.


Dave Enyeart
IBM Blockchain
enyeart@...

"Fu, Xinwen" ---03/28/2021 11:17:37 PM---Dear All, We want to say Hyperledger Fabric is a great blockchain framework and did not find issues

From: "Fu, Xinwen" <Xinwen_Fu@...>
To: David Enyeart <enyeart@...>, Brian Behlendorf <bbehlendorf@...>, "fabric@..." <fabric@...>
Cc: Manish Sethi1 <Manish.Sethi1@...>, "security@..." <security@...>, "Wang, Shan" <Shan_Wang@...>, Yue Zhang <zyueinfosec@...>
Date: 03/28/2021 11:17 PM
Subject: [EXTERNAL] RE: Security Analysis of Private Data Collection of Hyperledger Fabric





Dear All,

We want to say Hyperledger Fabric is a great blockchain framework and did not find issues with other parts of Hyperledger Fabric although the students spent a year on security analysis of the entire Hyperledger Fabric. I also think the students’ work shall be recognized by ICDCS.

We propose to put the following “Responsible Disclosure” statement into the paper and clarify your stance.

“Responsible Disclosure: The authors have communicated and reported the findings of this paper to the Hyperledger Fabric team since August 2020. According to the Hyperledger Fabric team, some findings reported in the paper are the design features and they may not cause security threats as the users may choose not to use them. We nevertheless report these findings here to raise user awareness and avoid security pitfalls.

Here is our response to some of the questions.

We agree with Brian: “we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).”.

The problem is kind of analogous to the issue with strcpy(). strcpy() is a feature of C, but causes buffer overflow attacks. Our paper shows potential attacks against some of the designs and proposes defense measures to defeat potential attacks.

Most of the related statements in the Hyperledger Fabric documents Dave provided in the email were added after we reported these issues at HackerOne below. We are wondering if we contributed to the refinement of the document.
https://hackerone.com/bugs?report_id=962705&subject=hyperledger
https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=951623&subject=hyperledger

We also believe that some attacks on PDC read-only transactions cannot be avoided by only following the documented guidance.
      1. For the third “vulnerability” on the exposed ``Payload” field in the transaction proposal response, under current design, if users choose to submit the read-only transaction for the proof purpose, the PDC will be definitely revealed to all peers in the same channel. To defeat such PDC leakage issues, we have proposed a solution in Section IV-C3 in our paper.

      2. For the second “vulnerability” (PDC transactions are validated through the chaincode-level policy by default), under current design, the read-only PDC transactions are validated always by the chaincode-level policy according to our source code analysis. Consequently, when users submit the PDC read-only transaction for the proof purpose, users can not use collection-level endorsement policies to further restrict which organization peers can endorse such transactions.


We also have disagreements on other arguments and have presented our reasoning in the paper.

Thanks.

Xinwen Fu
Professor
Department of Computer Science
University of Massachusetts Lowell
http://www.cs.uml.edu/~xinwenfu/



From: Fu, Xinwen
Sent:
Wednesday, March 24, 2021 11:20 PM
To:
David Enyeart <enyeart@...>; Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

Hi Dave and Brian,

Here is the third thread of our report to HackerOne: https://hackerone.com/bugs?report_id=951623&subject=hyperledger.

I’m currently tangled with other errands. We will post our followup to fabric@... by this weekend.

Regards,

Xinwen Fu

From: David Enyeart <enyeart@...>
Sent:
Wednesday, March 24, 2021 1:39 AM
To:
Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

This e-mail originated from outside the UMass Lowell network.


I have joined HackerOne now and added more details to the HackerOne resolutions.

I agree with Brian, since the reported vulnerabilities are features rather than vulnerabilities and already described in documentation with use cases and avoidance guidance, any further discussion would be appropriate on the Fabric mailing list.


Dave Enyeart
IBM Blockchain

enyeart@...

Brian Behlendorf ---03/24/2021 12:45:00 AM---First off, it's great news to see university research groups performing this kind of review of any

From:
Brian Behlendorf <bbehlendorf@...>
To:
"Fu, Xinwen" <Xinwen_Fu@...>, David Enyeart <enyeart@...>, "Wang, Shan" <Shan_Wang@...>
Cc:
"security@..." <security@...>, "wangshan@..." <wangshan@...>, Yue Zhang <zyueinfosec@...>, Manish Sethi1 <Manish.Sethi1@...>
Date:
03/24/2021 12:45 AM
Subject:
[EXTERNAL] Re: Security Analysis of Private Data Collection of Hyperledger Fabric





First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest

First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest of the team. And thank you Dave for such a rapid and thorough response.

Jumping in for context for others on security@: I found two threads from HackerOne on these issues:

https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=962705&subject=hyperledger

In both cases there were responses from Gari Singh that mostly mirrored Dave's reply, though without the fuller detail. Both ended with some remaining questions from the researchers, but there wasn't a closing follow up. After a couple of months for the first and a couple of weeks for the second, Ry closed them as "As designed".

There isn't an obligation from teams to satisfy everyone with replies, but this feels like the kind of conversation that should have been moved to a more public forum after the first replies from Gari. It's terrific that the initial reports were made privately just in case they had been serious issues, as that's proper practice, but when the conversations happen privately they can't help inform the next wave of users who believe they've found the same holes, or to address what may be gaps in documentation or even design that could be addressed.

Xinwen, would you feel comfortable posting your followup to Dave's points to the Fabric developer mailing list, at
fabric@...? You can join at https://lists.hyperledger.org/g/fabric

Dave, would you or other Fabric maintainers engage on this topic there?

I suspect at the very least this conversation would demonstrate that understanding the security issues around PDC and endorsement in general is really important, so as to avoid people using it incorrectly, or inadvertently leaving open holes. A research paper on that may be less sexy than one that achieves a CERT but it might also help advance the field anyways. What would be even more helpful would be suggested fixes or additions to the Fabric docs on the topic.

I also think we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).

Brian

On 3/23/21 9:07 PM, Fu, Xinwen wrote:
          Hi Dave,

          We have been reporting our research to Hyperledger Fabric through HackerOne since August 2020 while the reply at HackerOne was often super brief. We believe those designs in question are problematic and will provide more detailed explanation later.

          Thanks.

          Xinwen Fu
          Professor
          Department of Computer Science
          University of Massachusetts Lowell

          http://www.cs.uml.edu/~xinwenfu/



          From:
          David Enyeart <enyeart@...>
          Sent:
          Tuesday, March 23, 2021 11:37 PM
          To:
          Wang, Shan <Shan_Wang@...>
          Cc:
          security@...; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>; Manish Sethi1 <Manish.Sethi1@...>
          Subject:
          Re: Security Analysis of Private Data Collection of Hyperledger Fabric

          Hello, thank you for the submission. The reported vulnerabilities are actually not vulnerabilities however, but are working as designed. In fact, they are a critical and necessary aspect for how private data is used in many production solutions. And for use cases where the behavior is not desirable, it can be disabled and avoided through documented guidance. I will include links to the documentation that describe the appropriate use.
          Since the reported vulnerabilities are features of Fabric with appropriate use already documented, I would request that the paper be withdrawn.
          In the future, feel free to reach out to me or any of the Fabric maintainers, so that we can explain the design before you invest time in writing a paper.

          The first two reported vulnerabilities are related, therefore I will point out references in the Fabric documentation that describe the appropriate use of these aspects.

          (i) PDC Non-member peers can endorse PDC transactions;
          (ii) PDC transactions are validated through the same endorsement policy as public data transactions;


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data
          "You don’t necessarily have to be a member of a collection to write to a key in a collection, as long as the endorsement policy is satisfied. Endorsement policy can be defined at the chaincode level, key level (using state-based endorsement), or collection level (starting in Fabric v2.0)."

          "Sharing private data with other collections - You could ‘share’ the private data on-chain with chaincode that creates a matching key/value in the other organization’s private data collection. You’d pass the private data key/value to chaincode via transient field, and the chaincode could confirm a hash of the passed private data matches the on-chain hash from your collection using GetPrivateDataHash(), and then write the private data to the other organization’s private data collection."


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html
          "For write-only transactions, organizations that are not members of the collection distribution policy but are included in the chaincode level endorsement policy may endorse transactions that write to the private data collection. If this is not desirable, utilize a collection level
          endorsementPolicy to restrict the set of allowed endorsers to the private data distribution policy members."

          https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-collection-level-endorsement-policies
          "You can use collection-level endorsement policies to restrict which organization peers can write to the private data collection key namespace, for example to ensure that non-authorized organizations cannot write to a collection, and to have confidence that any state in a private data collection has been endorsed by the required collection organization(s)."

          "If you do not specify a collection-level endorsement policy, the chaincode-level endorsement policy will be applied to protect writes to a private data collection key namespace. This may be desirable if a set of organizations meeting the chaincode-level endorsement policy are authorized to create data in other organization’s private data collection. For example if those organizations are trusted to process transactions but are not authorized to store and later query private data due to industry privacy regulations, or if the private data is being shared or transferred from one set of organizations to another through the use of private data collections. In other scenarios, the private data collection members may need to be in full control of writes to the private data collection, in which case a collection-level endorsement policy should be provided."


          The third reported vulnerability is just something that chaincode authors need to be aware of, which has been added to the Fabric documentation:
          (iii) Exposed ``Payload” field in transaction proposal response.


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html#protecting-private-data-responses
          "Chaincode can return any data to a client application in the proposal response payload field. For read-only chaincode functions that query private data and which will not get submitted as transactions to the ordering service, private data may be returned in the proposal response payload field to the requesting client. For chaincode functions that propose private data writes however, take care not to include private data in the proposal response payload field, since this field will get included in the transaction which all channel members can access."

          Similarly, the reported attacks are not possible if the endorsement policies and proposal response payload are used per the documented guidance.


          Thank you,


          Dave Enyeart
          IBM Blockchain

          enyeart@...

          "Wang, Shan" ---03/23/2021 11:17:16 AM---Dear Hyperledger Fabric, We report some of our security analysis of the private data collections (PD

          From:
          "Wang, Shan" <Shan_Wang@...>
          To:
          "security@..." <security@...>
          Cc:
          "Fu, Xinwen" <Xinwen_Fu@...>, Yue Zhang <zyueinfosec@...>, "wangshan@..." <wangshan@...>
          Date:
          03/23/2021 11:17 AM
          Subject:
          [EXTERNAL] Security Analysis of Private Data Collection of Hyperledger Fabric







          Dear Hyperledger Fabric,

          We report some of our security analysis of the private data collections (PDC) to you and attached is a paper systematically presenting a complete security analysis. The paper will be published in July 2021 at the IEEE International Conference on Distributed Computing Systems (ICDCS).

          We believe we have discovered three design flaws on the private data collection in Hyperledger Fabric:
          (i) PDC Non-member peers can endorse PDC transactions;
          (ii) PDC transactions are validated through the same endorsement policy as public data transactions;
          (iii) Exposed ``Payload” field in transaction proposal response.

          We have discovered two classes of attacks against PDC transactions by exploiting the three design flaws:
          (i) Fake PDC results injection attack: malicious peers or clients may disrupt the integrity of the ledger. They may inject a valid transaction with a fake value into the blockchain or write fake values into the PDC in the ledger's world state.
          (ii) PDC leakage issues: the PDC can be revealed to PDC non-member peers and this violates the PDC design principles.

          We have designed defense measures to fix the three design flaws so as to defeat the discovered attacks, and implement these defense measures by modifying the source code of Hyperledger Fabric. Our patches have minor or negligible impact on the system performance.

          More details are presented in the attached paper. Please let us know if you have any questions.


          Best Regards,

          Shan Wang, Southeast University/University of Massachusetts Lowell
          Yue Zhang, Jinan University
          Xinwen Fu, University of Massachusetts Lowell



          (See attached file: Security Analysis of Private Data Collection of Hyperledger Fabric_report.pdf)
--
Brian Behlendorf
General Manager for Blockchain, Healthcare and Identity

bbehlendorf@...
Twitter: @brianbehlendorf

[attachment "Hyperledger_PDC_ICDCS2021_final.pdf" deleted by David Enyeart/Durham/IBM]





--
Best wishes!

Baohua Yang


Re: How to perform a "JOIN" using couchdb #couchdb #database

rodrigomelo9@...
 

FYI: we are working with the GO SDK, and we have a struct with idCategory (integer) and another structure with the idCategory and its value. I need to "join" the result. Maybe the solution is not related with coucdb's views (are they supported on HF)? Any comment will be appreciated.


How to perform a "JOIN" using couchdb #couchdb #database

rodrigomelo9@...
 

Hi. My name is Rodrigo and I am starting with HF (v2.2). Can someone point me a link about how to perform a JOIN (the equivalent map-reduce) using couchdb? I need a doc, an example, something (I googled for it without success). Or if not possible, or not recommended, what strategy to use. Thanks


Re: Security Analysis of Private Data Collection of Hyperledger Fabric

David Enyeart
 

As far as opening up the original HackerOne reports, I'd be fine with that if the process allows since the reports were resolved with documentation clarifications. The same documentation references are also copy/pasted from the reports into the email thread below (March 23rd response) for all to see.

Although closed as not vulnerabilities, the reports were worthwhile as they helped to identify areas where users may be confused and where documentation updates were required.


Dave Enyeart

"Senthil Nathan" ---03/30/2021 01:08:47 PM---These are neither design flaws nor vulnerabilities. We have various configuration parameters for pri

From: "Senthil Nathan" <cendhu@...>
To: Todd Little <toddjlittle@...>
Cc: fabric <fabric@...>
Date: 03/30/2021 01:08 PM
Subject: [EXTERNAL] Re: [Hyperledger Fabric] Security Analysis of Private Data Collection of Hyperledger Fabric
Sent by: fabric@...





These are neither design flaws nor vulnerabilities. We have various configuration parameters for private data collection. For example, the following is a configuration of a private data collection. { "name": "collectionMarblePrivateDetails" ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
These are neither design flaws nor vulnerabilities. We have various configuration parameters for private data collection. For example, the following is a configuration of a private data collection.
 {
   "name": "collectionMarblePrivateDetails",
   "policy": "OR('Org1MSP.member')",
   "requiredPeerCount": 0,
   "maxPeerCount": 3,
   "blockToLive":3,
   "memberOnlyRead": true,
   "memberOnlyWrite": true,
   "endorsementPolicy": {
     "signaturePolicy": "OR('Org1MSP.member')"
   }
}

Depending on the use-case, one can set the
memberOnlyRead and memberOnlyWrite to false. As a result,
a non-member can read and write to a collection. If an use-case wants a very restrictive access to the private
data collection, these parameters must be set to true. I don't think we can call this a design flaw. This is by
design and the documentation explains these configuration in details
(
https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data-arch.html)
Similarly, the endorsement policy can be set at the collection level as seen in the above configuration. It can also be at the key-level for more fine-grained control. Again, these are configuration parameters for the collection and the use-case dictates the required configuration.

I can go on but there are no design flaws or vulnerability in the Private Data Collection.

If the application/use-case does not configure the private data collection as per the need/requirement, it is not the fault of Hyperledger Fabric. For example, one must configure the firewall correctly in the production network. Without doing that, we cannot claim the networking stack in Linux Kernel to have vulnerabilities that allow unrestricted access.

I agree with Dave that the paper needs to be revised to say how to configure private data collections for various use-cases and requirements. 

Regards,
Senthil

On Tue, Mar 30, 2021 at 10:01 PM Todd Little <toddjlittle@...> wrote:
    As it appears the "issues" described in this paper are not really security issues, can the paper be made available to a wider audience?  Hackerone has all the reports related to this marked as private and inaccessible. Or can the reports be made public?

    Regards,
    Todd

    On 3/29/2021 9:28 AM, David Enyeart wrote:
        I still think it is in your best interest to make some minor updates to the paper content to avoid using sensational language such as "design flaws" and "vulnerabilities". Researchers tend to get discredited when their assertions get shown to be misleading or untrue. The original sponsor for the private data feature specifically requested the existing chaincode-level endorsement policy design for their use cases, and the more constrained collection-level endorsement policies were added as a parallel approach for other use cases. Calling out the original broadly as a design flaw is misleading and untrue when you consider the sponsor use case or review the Fabric documentation.

        I would very much support moving forward with the paper if it were recast as guidance for securing private data collections under various use case considerations.


        Dave Enyeart
        IBM Blockchain
        enyeart@...

        "Fu, Xinwen" ---03/28/2021 11:17:37 PM---Dear All, We want to say Hyperledger Fabric is a great blockchain framework and did not find issues

        From:
        "Fu, Xinwen" <Xinwen_Fu@...>
        To:
        David Enyeart <enyeart@...>, Brian Behlendorf <bbehlendorf@...>, "fabric@..." <fabric@...>
        Cc:
        Manish Sethi1 <Manish.Sethi1@...>, "security@..." <security@...>, "Wang, Shan" <Shan_Wang@...>, Yue Zhang <zyueinfosec@...>
        Date:
        03/28/2021 11:17 PM
        Subject:
        [EXTERNAL] RE: Security Analysis of Private Data Collection of Hyperledger Fabric





        Dear All,


        We want to say Hyperledger Fabric is a great blockchain framework and did not find issues with other parts of Hyperledger Fabric although the students spent a year on security analysis of the entire Hyperledger Fabric. I also think the students’ work shall be recognized by ICDCS.


        We propose to put the following “Responsible Disclosure” statement into the paper and clarify your stance.


        “Responsible Disclosure: The authors have communicated and reported the findings of this paper to the Hyperledger Fabric team since August 2020. According to the Hyperledger Fabric team, some findings reported in the paper are the design features and they may not cause security threats as the users may choose not to use them. We nevertheless report these findings here to raise user awareness and avoid security pitfalls.


        Here is our response to some of the questions.


        We agree with Brian: “we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).”.


        The problem is kind of analogous to the issue with strcpy(). strcpy() is a feature of C, but causes buffer overflow attacks. Our paper shows potential attacks against some of the designs and proposes defense measures to defeat potential attacks.


        Most of the related statements in the Hyperledger Fabric documents Dave provided in the email were added after we reported these issues at HackerOne below. We are wondering if we contributed to the refinement of the document.

        https://hackerone.com/bugs?report_id=962705&subject=hyperledger
        https://hackerone.com/bugs?report_id=926222&subject=hyperledger
        https://hackerone.com/bugs?report_id=951623&subject=hyperledger

        We also believe that some attacks on PDC read-only transactions cannot be avoided by only following the documented guidance.
                1. For the third “vulnerability” on the exposed ``Payload” field in the transaction proposal response, under current design, if users choose to submit the read-only transaction for the proof purpose, the PDC will be definitely revealed to all peers in the same channel. To defeat such PDC leakage issues, we have proposed a solution in Section IV-C3 in our paper.

                2. For the second “vulnerability” (PDC transactions are validated through the chaincode-level policy by default), under current design, the read-only PDC transactions are validated always by the chaincode-level policy according to our source code analysis. Consequently, when users submit the PDC read-only transaction for the proof purpose, users can not use collection-level endorsement policies to further restrict which organization peers can endorse such transactions.


        We also have disagreements on other arguments and have presented our reasoning in the paper.


        Thanks.


        Xinwen Fu
        Professor
        Department of Computer Science
        University of Massachusetts Lowell

        http://www.cs.uml.edu/~xinwenfu/



From: Fu, Xinwen
Sent:
Wednesday, March 24, 2021 11:20 PM
To:
David Enyeart <enyeart@...>; Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

Hi Dave and Brian,


Here is the third thread of our report to HackerOne:
https://hackerone.com/bugs?report_id=951623&subject=hyperledger.

I’m currently tangled with other errands. We will post our followup to
fabric@... by this weekend.

Regards,


Xinwen Fu


From:
David Enyeart <enyeart@...>
Sent:
Wednesday, March 24, 2021 1:39 AM
To:
Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

This e-mail originated from outside the UMass Lowell network.


I have joined HackerOne now and added more details to the HackerOne resolutions.

I agree with Brian, since the reported vulnerabilities are features rather than vulnerabilities and already described in documentation with use cases and avoidance guidance, any further discussion would be appropriate on the Fabric mailing list.



Dave Enyeart
IBM Blockchain

enyeart@...

Brian Behlendorf ---03/24/2021 12:45:00 AM---First off, it's great news to see university research groups performing this kind of review of any

From:
Brian Behlendorf <bbehlendorf@...>
To:
"Fu, Xinwen" <Xinwen_Fu@...>, David Enyeart <enyeart@...>, "Wang, Shan" <Shan_Wang@...>
Cc:
"security@..." <security@...>, "wangshan@..." <wangshan@...>, Yue Zhang <zyueinfosec@...>, Manish Sethi1 <Manish.Sethi1@...>
Date:
03/24/2021 12:45 AM
Subject:
[EXTERNAL] Re: Security Analysis of Private Data Collection of Hyperledger Fabric





First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest

First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest of the team. And thank you Dave for such a rapid and thorough response.

Jumping in for context for others on security@: I found two threads from HackerOne on these issues:


https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=962705&subject=hyperledger

In both cases there were responses from Gari Singh that mostly mirrored Dave's reply, though without the fuller detail. Both ended with some remaining questions from the researchers, but there wasn't a closing follow up. After a couple of months for the first and a couple of weeks for the second, Ry closed them as "As designed".

There isn't an obligation from teams to satisfy everyone with replies, but this feels like the kind of conversation that should have been moved to a more public forum after the first replies from Gari. It's terrific that the initial reports were made privately just in case they had been serious issues, as that's proper practice, but when the conversations happen privately they can't help inform the next wave of users who believe they've found the same holes, or to address what may be gaps in documentation or even design that could be addressed.

Xinwen, would you feel comfortable posting your followup to Dave's points to the Fabric developer mailing list, at
fabric@...? You can join at https://lists.hyperledger.org/g/fabric

Dave, would you or other Fabric maintainers engage on this topic there?

I suspect at the very least this conversation would demonstrate that understanding the security issues around PDC and endorsement in general is really important, so as to avoid people using it incorrectly, or inadvertently leaving open holes. A research paper on that may be less sexy than one that achieves a CERT but it might also help advance the field anyways. What would be even more helpful would be suggested fixes or additions to the Fabric docs on the topic.

I also think we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).

Brian

On 3/23/21 9:07 PM, Fu, Xinwen wrote:
                  Hi Dave,

                  We have been reporting our research to Hyperledger Fabric through HackerOne since August 2020 while the reply at HackerOne was often super brief. We believe those designs in question are problematic and will provide more detailed explanation later.

                  Thanks.

                  Xinwen Fu
                  Professor
                  Department of Computer Science
                  University of Massachusetts Lowell

                  http://www.cs.uml.edu/~xinwenfu/



                  From:
                  David Enyeart <enyeart@...>
                  Sent:
                  Tuesday, March 23, 2021 11:37 PM
                  To:
                  Wang, Shan <Shan_Wang@...>
                  Cc:
                  security@...; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>; Manish Sethi1 <Manish.Sethi1@...>
                  Subject:
                  Re: Security Analysis of Private Data Collection of Hyperledger Fabric

                  Hello, thank you for the submission. The reported vulnerabilities are actually not vulnerabilities however, but are working as designed. In fact, they are a critical and necessary aspect for how private data is used in many production solutions. And for use cases where the behavior is not desirable, it can be disabled and avoided through documented guidance. I will include links to the documentation that describe the appropriate use.
                  Since the reported vulnerabilities are features of Fabric with appropriate use already documented, I would request that the paper be withdrawn.
                  In the future, feel free to reach out to me or any of the Fabric maintainers, so that we can explain the design before you invest time in writing a paper.

                  The first two reported vulnerabilities are related, therefore I will point out references in the Fabric documentation that describe the appropriate use of these aspects.

                  (i) PDC Non-member peers can endorse PDC transactions;
                  (ii) PDC transactions are validated through the same endorsement policy as public data transactions;


                  https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data
                  "You don’t necessarily have to be a member of a collection to write to a key in a collection, as long as the endorsement policy is satisfied. Endorsement policy can be defined at the chaincode level, key level (using state-based endorsement), or collection level (starting in Fabric v2.0)."

                  "Sharing private data with other collections - You could ‘share’ the private data on-chain with chaincode that creates a matching key/value in the other organization’s private data collection. You’d pass the private data key/value to chaincode via transient field, and the chaincode could confirm a hash of the passed private data matches the on-chain hash from your collection using GetPrivateDataHash(), and then write the private data to the other organization’s private data collection."


                  https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html
                  "For write-only transactions, organizations that are not members of the collection distribution policy but are included in the chaincode level endorsement policy may endorse transactions that write to the private data collection. If this is not desirable, utilize a collection level
                  endorsementPolicy to restrict the set of allowed endorsers to the private data distribution policy members."

                  https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-collection-level-endorsement-policies
                  "You can use collection-level endorsement policies to restrict which organization peers can write to the private data collection key namespace, for example to ensure that non-authorized organizations cannot write to a collection, and to have confidence that any state in a private data collection has been endorsed by the required collection organization(s)."

                  "If you do not specify a collection-level endorsement policy, the chaincode-level endorsement policy will be applied to protect writes to a private data collection key namespace. This may be desirable if a set of organizations meeting the chaincode-level endorsement policy are authorized to create data in other organization’s private data collection. For example if those organizations are trusted to process transactions but are not authorized to store and later query private data due to industry privacy regulations, or if the private data is being shared or transferred from one set of organizations to another through the use of private data collections. In other scenarios, the private data collection members may need to be in full control of writes to the private data collection, in which case a collection-level endorsement policy should be provided."


                  The third reported vulnerability is just something that chaincode authors need to be aware of, which has been added to the Fabric documentation:
                  (iii) Exposed ``Payload” field in transaction proposal response.


                  https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html#protecting-private-data-responses
                  "Chaincode can return any data to a client application in the proposal response payload field. For read-only chaincode functions that query private data and which will not get submitted as transactions to the ordering service, private data may be returned in the proposal response payload field to the requesting client. For chaincode functions that propose private data writes however, take care not to include private data in the proposal response payload field, since this field will get included in the transaction which all channel members can access."

                  Similarly, the reported attacks are not possible if the endorsement policies and proposal response payload are used per the documented guidance.


                  Thank you,


                  Dave Enyeart
                  IBM Blockchain

                  enyeart@...

                  "Wang, Shan" ---03/23/2021 11:17:16 AM---Dear Hyperledger Fabric, We report some of our security analysis of the private data collections (PD

                  From:
                  "Wang, Shan" <Shan_Wang@...>
                  To:
                  "security@..." <security@...>
                  Cc:
                  "Fu, Xinwen" <Xinwen_Fu@...>, Yue Zhang <zyueinfosec@...>, "wangshan@..." <wangshan@...>
                  Date:
                  03/23/2021 11:17 AM
                  Subject:
                  [EXTERNAL] Security Analysis of Private Data Collection of Hyperledger Fabric







                  Dear Hyperledger Fabric,

                  We report some of our security analysis of the private data collections (PDC) to you and attached is a paper systematically presenting a complete security analysis. The paper will be published in July 2021 at the IEEE International Conference on Distributed Computing Systems (ICDCS).

                  We believe we have discovered three design flaws on the private data collection in Hyperledger Fabric:
                  (i) PDC Non-member peers can endorse PDC transactions;
                  (ii) PDC transactions are validated through the same endorsement policy as public data transactions;
                  (iii) Exposed ``Payload” field in transaction proposal response.

                  We have discovered two classes of attacks against PDC transactions by exploiting the three design flaws:
                  (i) Fake PDC results injection attack: malicious peers or clients may disrupt the integrity of the ledger. They may inject a valid transaction with a fake value into the blockchain or write fake values into the PDC in the ledger's world state.
                  (ii) PDC leakage issues: the PDC can be revealed to PDC non-member peers and this violates the PDC design principles.

                  We have designed defense measures to fix the three design flaws so as to defeat the discovered attacks, and implement these defense measures by modifying the source code of Hyperledger Fabric. Our patches have minor or negligible impact on the system performance.

                  More details are presented in the attached paper. Please let us know if you have any questions.


                  Best Regards,

                  Shan Wang, Southeast University/University of Massachusetts Lowell
                  Yue Zhang, Jinan University
                  Xinwen Fu, University of Massachusetts Lowell



                  (See attached file: Security Analysis of Private Data Collection of Hyperledger Fabric_report.pdf)
--
Brian Behlendorf
General Manager for Blockchain, Healthcare and Identity

bbehlendorf@...
Twitter: @brianbehlendorf

[attachment "Hyperledger_PDC_ICDCS2021_final.pdf" deleted by David Enyeart/Durham/IBM]






Re: Security Analysis of Private Data Collection of Hyperledger Fabric

Senthil Nathan
 

These are neither design flaws nor vulnerabilities. We have various configuration parameters for private data collection. For example, the following is a configuration of a private data collection.
 {
    "name": "collectionMarblePrivateDetails",
    "policy": "OR('Org1MSP.member')",
    "requiredPeerCount": 0,
    "maxPeerCount": 3,
    "blockToLive":3,
    "memberOnlyRead": true,
    "memberOnlyWrite": true,
    "endorsementPolicy": {
      "signaturePolicy": "OR('Org1MSP.member')"
    }
 }

Depending on the use-case, one can set the memberOnlyRead and memberOnlyWrite to false. As a result,
a non-member can read and write to a collection. If an use-case wants a very restrictive access to the private
data collection, these parameters must be set to true. I don't think we can call this a design flaw. This is by
design and the documentation explains these configuration in details
(https://hyperledger-fabric.readthedocs.io/en/release-2.2/private-data-arch.html)
Similarly, the endorsement policy can be set at the collection level as seen in the above configuration. It can also be at the key-level for more fine-grained control. Again, these are configuration parameters for the collection and the use-case dictates the required configuration.

I can go on but there are no design flaws or vulnerability in the Private Data Collection.

If the application/use-case does not configure the private data collection as per the need/requirement, it is not the fault of Hyperledger Fabric. For example, one must configure the firewall correctly in the production network. Without doing that, we cannot claim the networking stack in Linux Kernel to have vulnerabilities that allow unrestricted access.

I agree with Dave that the paper needs to be revised to say how to configure private data collections for various use-cases and requirements. 

Regards,
Senthil

On Tue, Mar 30, 2021 at 10:01 PM Todd Little <toddjlittle@...> wrote:
As it appears the "issues" described in this paper are not really security issues, can the paper be made available to a wider audience?  Hackerone has all the reports related to this marked as private and inaccessible. Or can the reports be made public?

Regards,
Todd

On 3/29/2021 9:28 AM, David Enyeart wrote:

I still think it is in your best interest to make some minor updates to the paper content to avoid using sensational language such as "design flaws" and "vulnerabilities". Researchers tend to get discredited when their assertions get shown to be misleading or untrue. The original sponsor for the private data feature specifically requested the existing chaincode-level endorsement policy design for their use cases, and the more constrained collection-level endorsement policies were added as a parallel approach for other use cases. Calling out the original broadly as a design flaw is misleading and untrue when you consider the sponsor use case or review the Fabric documentation.

I would very much support moving forward with the paper if it were recast as guidance for securing private data collections under various use case considerations.


Dave Enyeart
IBM Blockchain
enyeart@...

"Fu, Xinwen" ---03/28/2021 11:17:37 PM---Dear All, We want to say Hyperledger Fabric is a great blockchain framework and did not find issues

From: "Fu, Xinwen" <Xinwen_Fu@...>
To: David Enyeart <enyeart@...>, Brian Behlendorf <bbehlendorf@...>, "fabric@..." <fabric@...>
Cc: Manish Sethi1 <Manish.Sethi1@...>, "security@..." <security@...>, "Wang, Shan" <Shan_Wang@...>, Yue Zhang <zyueinfosec@...>
Date: 03/28/2021 11:17 PM
Subject: [EXTERNAL] RE: Security Analysis of Private Data Collection of Hyperledger Fabric





Dear All,

We want to say Hyperledger Fabric is a great blockchain framework and did not find issues with other parts of Hyperledger Fabric although the students spent a year on security analysis of the entire Hyperledger Fabric. I also think the students’ work shall be recognized by ICDCS.

We propose to put the following “Responsible Disclosure” statement into the paper and clarify your stance.

“Responsible Disclosure: The authors have communicated and reported the findings of this paper to the Hyperledger Fabric team since August 2020. According to the Hyperledger Fabric team, some findings reported in the paper are the design features and they may not cause security threats as the users may choose not to use them. We nevertheless report these findings here to raise user awareness and avoid security pitfalls.

Here is our response to some of the questions.

We agree with Brian: “we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).”.

The problem is kind of analogous to the issue with strcpy(). strcpy() is a feature of C, but causes buffer overflow attacks. Our paper shows potential attacks against some of the designs and proposes defense measures to defeat potential attacks.

Most of the related statements in the Hyperledger Fabric documents Dave provided in the email were added after we reported these issues at HackerOne below. We are wondering if we contributed to the refinement of the document.
https://hackerone.com/bugs?report_id=962705&subject=hyperledger
https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=951623&subject=hyperledger

We also believe that some attacks on PDC read-only transactions cannot be avoided by only following the documented guidance.
      1. For the third “vulnerability” on the exposed ``Payload” field in the transaction proposal response, under current design, if users choose to submit the read-only transaction for the proof purpose, the PDC will be definitely revealed to all peers in the same channel. To defeat such PDC leakage issues, we have proposed a solution in Section IV-C3 in our paper.

      2. For the second “vulnerability” (PDC transactions are validated through the chaincode-level policy by default), under current design, the read-only PDC transactions are validated always by the chaincode-level policy according to our source code analysis. Consequently, when users submit the PDC read-only transaction for the proof purpose, users can not use collection-level endorsement policies to further restrict which organization peers can endorse such transactions.


We also have disagreements on other arguments and have presented our reasoning in the paper.

Thanks.

Xinwen Fu
Professor
Department of Computer Science
University of Massachusetts Lowell
http://www.cs.uml.edu/~xinwenfu/



From: Fu, Xinwen
Sent:
Wednesday, March 24, 2021 11:20 PM
To:
David Enyeart <enyeart@...>; Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

Hi Dave and Brian,

Here is the third thread of our report to HackerOne: https://hackerone.com/bugs?report_id=951623&subject=hyperledger.

I’m currently tangled with other errands. We will post our followup to fabric@... by this weekend.

Regards,

Xinwen Fu

From: David Enyeart <enyeart@...>
Sent:
Wednesday, March 24, 2021 1:39 AM
To:
Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

This e-mail originated from outside the UMass Lowell network.


I have joined HackerOne now and added more details to the HackerOne resolutions.

I agree with Brian, since the reported vulnerabilities are features rather than vulnerabilities and already described in documentation with use cases and avoidance guidance, any further discussion would be appropriate on the Fabric mailing list.


Dave Enyeart
IBM Blockchain

enyeart@...

Brian Behlendorf ---03/24/2021 12:45:00 AM---First off, it's great news to see university research groups performing this kind of review of any

From:
Brian Behlendorf <bbehlendorf@...>
To:
"Fu, Xinwen" <Xinwen_Fu@...>, David Enyeart <enyeart@...>, "Wang, Shan" <Shan_Wang@...>
Cc:
"security@..." <security@...>, "wangshan@..." <wangshan@...>, Yue Zhang <zyueinfosec@...>, Manish Sethi1 <Manish.Sethi1@...>
Date:
03/24/2021 12:45 AM
Subject:
[EXTERNAL] Re: Security Analysis of Private Data Collection of Hyperledger Fabric





First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest

First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest of the team. And thank you Dave for such a rapid and thorough response.

Jumping in for context for others on security@: I found two threads from HackerOne on these issues:

https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=962705&subject=hyperledger

In both cases there were responses from Gari Singh that mostly mirrored Dave's reply, though without the fuller detail. Both ended with some remaining questions from the researchers, but there wasn't a closing follow up. After a couple of months for the first and a couple of weeks for the second, Ry closed them as "As designed".

There isn't an obligation from teams to satisfy everyone with replies, but this feels like the kind of conversation that should have been moved to a more public forum after the first replies from Gari. It's terrific that the initial reports were made privately just in case they had been serious issues, as that's proper practice, but when the conversations happen privately they can't help inform the next wave of users who believe they've found the same holes, or to address what may be gaps in documentation or even design that could be addressed.

Xinwen, would you feel comfortable posting your followup to Dave's points to the Fabric developer mailing list, at
fabric@...? You can join at https://lists.hyperledger.org/g/fabric

Dave, would you or other Fabric maintainers engage on this topic there?

I suspect at the very least this conversation would demonstrate that understanding the security issues around PDC and endorsement in general is really important, so as to avoid people using it incorrectly, or inadvertently leaving open holes. A research paper on that may be less sexy than one that achieves a CERT but it might also help advance the field anyways. What would be even more helpful would be suggested fixes or additions to the Fabric docs on the topic.

I also think we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).

Brian

On 3/23/21 9:07 PM, Fu, Xinwen wrote:
          Hi Dave,

          We have been reporting our research to Hyperledger Fabric through HackerOne since August 2020 while the reply at HackerOne was often super brief. We believe those designs in question are problematic and will provide more detailed explanation later.

          Thanks.

          Xinwen Fu
          Professor
          Department of Computer Science
          University of Massachusetts Lowell

          http://www.cs.uml.edu/~xinwenfu/



          From:
          David Enyeart <enyeart@...>
          Sent:
          Tuesday, March 23, 2021 11:37 PM
          To:
          Wang, Shan <Shan_Wang@...>
          Cc:
          security@...; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>; Manish Sethi1 <Manish.Sethi1@...>
          Subject:
          Re: Security Analysis of Private Data Collection of Hyperledger Fabric

          Hello, thank you for the submission. The reported vulnerabilities are actually not vulnerabilities however, but are working as designed. In fact, they are a critical and necessary aspect for how private data is used in many production solutions. And for use cases where the behavior is not desirable, it can be disabled and avoided through documented guidance. I will include links to the documentation that describe the appropriate use.
          Since the reported vulnerabilities are features of Fabric with appropriate use already documented, I would request that the paper be withdrawn.
          In the future, feel free to reach out to me or any of the Fabric maintainers, so that we can explain the design before you invest time in writing a paper.

          The first two reported vulnerabilities are related, therefore I will point out references in the Fabric documentation that describe the appropriate use of these aspects.

          (i) PDC Non-member peers can endorse PDC transactions;
          (ii) PDC transactions are validated through the same endorsement policy as public data transactions;


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data
          "You don’t necessarily have to be a member of a collection to write to a key in a collection, as long as the endorsement policy is satisfied. Endorsement policy can be defined at the chaincode level, key level (using state-based endorsement), or collection level (starting in Fabric v2.0)."

          "Sharing private data with other collections - You could ‘share’ the private data on-chain with chaincode that creates a matching key/value in the other organization’s private data collection. You’d pass the private data key/value to chaincode via transient field, and the chaincode could confirm a hash of the passed private data matches the on-chain hash from your collection using GetPrivateDataHash(), and then write the private data to the other organization’s private data collection."


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html
          "For write-only transactions, organizations that are not members of the collection distribution policy but are included in the chaincode level endorsement policy may endorse transactions that write to the private data collection. If this is not desirable, utilize a collection level
          endorsementPolicy to restrict the set of allowed endorsers to the private data distribution policy members."

          https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-collection-level-endorsement-policies
          "You can use collection-level endorsement policies to restrict which organization peers can write to the private data collection key namespace, for example to ensure that non-authorized organizations cannot write to a collection, and to have confidence that any state in a private data collection has been endorsed by the required collection organization(s)."

          "If you do not specify a collection-level endorsement policy, the chaincode-level endorsement policy will be applied to protect writes to a private data collection key namespace. This may be desirable if a set of organizations meeting the chaincode-level endorsement policy are authorized to create data in other organization’s private data collection. For example if those organizations are trusted to process transactions but are not authorized to store and later query private data due to industry privacy regulations, or if the private data is being shared or transferred from one set of organizations to another through the use of private data collections. In other scenarios, the private data collection members may need to be in full control of writes to the private data collection, in which case a collection-level endorsement policy should be provided."


          The third reported vulnerability is just something that chaincode authors need to be aware of, which has been added to the Fabric documentation:
          (iii) Exposed ``Payload” field in transaction proposal response.


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html#protecting-private-data-responses
          "Chaincode can return any data to a client application in the proposal response payload field. For read-only chaincode functions that query private data and which will not get submitted as transactions to the ordering service, private data may be returned in the proposal response payload field to the requesting client. For chaincode functions that propose private data writes however, take care not to include private data in the proposal response payload field, since this field will get included in the transaction which all channel members can access."

          Similarly, the reported attacks are not possible if the endorsement policies and proposal response payload are used per the documented guidance.


          Thank you,


          Dave Enyeart
          IBM Blockchain

          enyeart@...

          "Wang, Shan" ---03/23/2021 11:17:16 AM---Dear Hyperledger Fabric, We report some of our security analysis of the private data collections (PD

          From:
          "Wang, Shan" <Shan_Wang@...>
          To:
          "security@..." <security@...>
          Cc:
          "Fu, Xinwen" <Xinwen_Fu@...>, Yue Zhang <zyueinfosec@...>, "wangshan@..." <wangshan@...>
          Date:
          03/23/2021 11:17 AM
          Subject:
          [EXTERNAL] Security Analysis of Private Data Collection of Hyperledger Fabric







          Dear Hyperledger Fabric,

          We report some of our security analysis of the private data collections (PDC) to you and attached is a paper systematically presenting a complete security analysis. The paper will be published in July 2021 at the IEEE International Conference on Distributed Computing Systems (ICDCS).

          We believe we have discovered three design flaws on the private data collection in Hyperledger Fabric:
          (i) PDC Non-member peers can endorse PDC transactions;
          (ii) PDC transactions are validated through the same endorsement policy as public data transactions;
          (iii) Exposed ``Payload” field in transaction proposal response.

          We have discovered two classes of attacks against PDC transactions by exploiting the three design flaws:
          (i) Fake PDC results injection attack: malicious peers or clients may disrupt the integrity of the ledger. They may inject a valid transaction with a fake value into the blockchain or write fake values into the PDC in the ledger's world state.
          (ii) PDC leakage issues: the PDC can be revealed to PDC non-member peers and this violates the PDC design principles.

          We have designed defense measures to fix the three design flaws so as to defeat the discovered attacks, and implement these defense measures by modifying the source code of Hyperledger Fabric. Our patches have minor or negligible impact on the system performance.

          More details are presented in the attached paper. Please let us know if you have any questions.


          Best Regards,

          Shan Wang, Southeast University/University of Massachusetts Lowell
          Yue Zhang, Jinan University
          Xinwen Fu, University of Massachusetts Lowell



          (See attached file: Security Analysis of Private Data Collection of Hyperledger Fabric_report.pdf)
--
Brian Behlendorf
General Manager for Blockchain, Healthcare and Identity

bbehlendorf@...
Twitter: @brianbehlendorf

[attachment "Hyperledger_PDC_ICDCS2021_final.pdf" deleted by David Enyeart/Durham/IBM]




Re: Security Analysis of Private Data Collection of Hyperledger Fabric

Todd Little
 

As it appears the "issues" described in this paper are not really security issues, can the paper be made available to a wider audience?  Hackerone has all the reports related to this marked as private and inaccessible. Or can the reports be made public?

Regards,
Todd

On 3/29/2021 9:28 AM, David Enyeart wrote:

I still think it is in your best interest to make some minor updates to the paper content to avoid using sensational language such as "design flaws" and "vulnerabilities". Researchers tend to get discredited when their assertions get shown to be misleading or untrue. The original sponsor for the private data feature specifically requested the existing chaincode-level endorsement policy design for their use cases, and the more constrained collection-level endorsement policies were added as a parallel approach for other use cases. Calling out the original broadly as a design flaw is misleading and untrue when you consider the sponsor use case or review the Fabric documentation.

I would very much support moving forward with the paper if it were recast as guidance for securing private data collections under various use case considerations.


Dave Enyeart
IBM Blockchain
enyeart@...

"Fu, Xinwen" ---03/28/2021 11:17:37 PM---Dear All, We want to say Hyperledger Fabric is a great blockchain framework and did not find issues

From: "Fu, Xinwen" <Xinwen_Fu@...>
To: David Enyeart <enyeart@...>, Brian Behlendorf <bbehlendorf@...>, "fabric@..." <fabric@...>
Cc: Manish Sethi1 <Manish.Sethi1@...>, "security@..." <security@...>, "Wang, Shan" <Shan_Wang@...>, Yue Zhang <zyueinfosec@...>
Date: 03/28/2021 11:17 PM
Subject: [EXTERNAL] RE: Security Analysis of Private Data Collection of Hyperledger Fabric





Dear All,

We want to say Hyperledger Fabric is a great blockchain framework and did not find issues with other parts of Hyperledger Fabric although the students spent a year on security analysis of the entire Hyperledger Fabric. I also think the students’ work shall be recognized by ICDCS.

We propose to put the following “Responsible Disclosure” statement into the paper and clarify your stance.

“Responsible Disclosure: The authors have communicated and reported the findings of this paper to the Hyperledger Fabric team since August 2020. According to the Hyperledger Fabric team, some findings reported in the paper are the design features and they may not cause security threats as the users may choose not to use them. We nevertheless report these findings here to raise user awareness and avoid security pitfalls.

Here is our response to some of the questions.

We agree with Brian: “we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).”.

The problem is kind of analogous to the issue with strcpy(). strcpy() is a feature of C, but causes buffer overflow attacks. Our paper shows potential attacks against some of the designs and proposes defense measures to defeat potential attacks.

Most of the related statements in the Hyperledger Fabric documents Dave provided in the email were added after we reported these issues at HackerOne below. We are wondering if we contributed to the refinement of the document.
https://hackerone.com/bugs?report_id=962705&subject=hyperledger
https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=951623&subject=hyperledger

We also believe that some attacks on PDC read-only transactions cannot be avoided by only following the documented guidance.
      1. For the third “vulnerability” on the exposed ``Payload” field in the transaction proposal response, under current design, if users choose to submit the read-only transaction for the proof purpose, the PDC will be definitely revealed to all peers in the same channel. To defeat such PDC leakage issues, we have proposed a solution in Section IV-C3 in our paper.

      2. For the second “vulnerability” (PDC transactions are validated through the chaincode-level policy by default), under current design, the read-only PDC transactions are validated always by the chaincode-level policy according to our source code analysis. Consequently, when users submit the PDC read-only transaction for the proof purpose, users can not use collection-level endorsement policies to further restrict which organization peers can endorse such transactions.


We also have disagreements on other arguments and have presented our reasoning in the paper.

Thanks.

Xinwen Fu
Professor
Department of Computer Science
University of Massachusetts Lowell
http://www.cs.uml.edu/~xinwenfu/



From: Fu, Xinwen
Sent:
Wednesday, March 24, 2021 11:20 PM
To:
David Enyeart <enyeart@...>; Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

Hi Dave and Brian,

Here is the third thread of our report to HackerOne: https://hackerone.com/bugs?report_id=951623&subject=hyperledger.

I’m currently tangled with other errands. We will post our followup to fabric@... by this weekend.

Regards,

Xinwen Fu

From: David Enyeart <enyeart@...>
Sent:
Wednesday, March 24, 2021 1:39 AM
To:
Brian Behlendorf <bbehlendorf@...>
Cc:
Manish Sethi1 <Manish.Sethi1@...>; security@...; Wang, Shan <Shan_Wang@...>; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>
Subject:
RE: Security Analysis of Private Data Collection of Hyperledger Fabric

This e-mail originated from outside the UMass Lowell network.


I have joined HackerOne now and added more details to the HackerOne resolutions.

I agree with Brian, since the reported vulnerabilities are features rather than vulnerabilities and already described in documentation with use cases and avoidance guidance, any further discussion would be appropriate on the Fabric mailing list.


Dave Enyeart
IBM Blockchain

enyeart@...

Brian Behlendorf ---03/24/2021 12:45:00 AM---First off, it's great news to see university research groups performing this kind of review of any

From:
Brian Behlendorf <bbehlendorf@...>
To:
"Fu, Xinwen" <Xinwen_Fu@...>, David Enyeart <enyeart@...>, "Wang, Shan" <Shan_Wang@...>
Cc:
"security@..." <security@...>, "wangshan@..." <wangshan@...>, Yue Zhang <zyueinfosec@...>, Manish Sethi1 <Manish.Sethi1@...>
Date:
03/24/2021 12:45 AM
Subject:
[EXTERNAL] Re: Security Analysis of Private Data Collection of Hyperledger Fabric





First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest

First off, it's great news to see university research groups performing this kind of review of any Hyperledger project, and I for one am appreciative of the interest. even if the end results are educational. Thank you to Mr. Fu and the rest of the team. And thank you Dave for such a rapid and thorough response.

Jumping in for context for others on security@: I found two threads from HackerOne on these issues:

https://hackerone.com/bugs?report_id=926222&subject=hyperledger
https://hackerone.com/bugs?report_id=962705&subject=hyperledger

In both cases there were responses from Gari Singh that mostly mirrored Dave's reply, though without the fuller detail. Both ended with some remaining questions from the researchers, but there wasn't a closing follow up. After a couple of months for the first and a couple of weeks for the second, Ry closed them as "As designed".

There isn't an obligation from teams to satisfy everyone with replies, but this feels like the kind of conversation that should have been moved to a more public forum after the first replies from Gari. It's terrific that the initial reports were made privately just in case they had been serious issues, as that's proper practice, but when the conversations happen privately they can't help inform the next wave of users who believe they've found the same holes, or to address what may be gaps in documentation or even design that could be addressed.

Xinwen, would you feel comfortable posting your followup to Dave's points to the Fabric developer mailing list, at
fabric@...? You can join at https://lists.hyperledger.org/g/fabric

Dave, would you or other Fabric maintainers engage on this topic there?

I suspect at the very least this conversation would demonstrate that understanding the security issues around PDC and endorsement in general is really important, so as to avoid people using it incorrectly, or inadvertently leaving open holes. A research paper on that may be less sexy than one that achieves a CERT but it might also help advance the field anyways. What would be even more helpful would be suggested fixes or additions to the Fabric docs on the topic.

I also think we should not assume that Fabric networks will always be small and all users will be trusted - if there are opportunities for abuse by peers or even orderers who have been compromised, those should be closed down by design (or at least by default).

Brian

On 3/23/21 9:07 PM, Fu, Xinwen wrote:
          Hi Dave,

          We have been reporting our research to Hyperledger Fabric through HackerOne since August 2020 while the reply at HackerOne was often super brief. We believe those designs in question are problematic and will provide more detailed explanation later.

          Thanks.

          Xinwen Fu
          Professor
          Department of Computer Science
          University of Massachusetts Lowell

          http://www.cs.uml.edu/~xinwenfu/



          From:
          David Enyeart <enyeart@...>
          Sent:
          Tuesday, March 23, 2021 11:37 PM
          To:
          Wang, Shan <Shan_Wang@...>
          Cc:
          security@...; wangshan@...; Fu, Xinwen <Xinwen_Fu@...>; Yue Zhang <zyueinfosec@...>; Manish Sethi1 <Manish.Sethi1@...>
          Subject:
          Re: Security Analysis of Private Data Collection of Hyperledger Fabric

          Hello, thank you for the submission. The reported vulnerabilities are actually not vulnerabilities however, but are working as designed. In fact, they are a critical and necessary aspect for how private data is used in many production solutions. And for use cases where the behavior is not desirable, it can be disabled and avoided through documented guidance. I will include links to the documentation that describe the appropriate use.
          Since the reported vulnerabilities are features of Fabric with appropriate use already documented, I would request that the paper be withdrawn.
          In the future, feel free to reach out to me or any of the Fabric maintainers, so that we can explain the design before you invest time in writing a paper.

          The first two reported vulnerabilities are related, therefore I will point out references in the Fabric documentation that describe the appropriate use of these aspects.

          (i) PDC Non-member peers can endorse PDC transactions;
          (ii) PDC transactions are validated through the same endorsement policy as public data transactions;


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data
          "You don’t necessarily have to be a member of a collection to write to a key in a collection, as long as the endorsement policy is satisfied. Endorsement policy can be defined at the chaincode level, key level (using state-based endorsement), or collection level (starting in Fabric v2.0)."

          "Sharing private data with other collections - You could ‘share’ the private data on-chain with chaincode that creates a matching key/value in the other organization’s private data collection. You’d pass the private data key/value to chaincode via transient field, and the chaincode could confirm a hash of the passed private data matches the on-chain hash from your collection using GetPrivateDataHash(), and then write the private data to the other organization’s private data collection."


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html
          "For write-only transactions, organizations that are not members of the collection distribution policy but are included in the chaincode level endorsement policy may endorse transactions that write to the private data collection. If this is not desirable, utilize a collection level
          endorsementPolicy to restrict the set of allowed endorsers to the private data distribution policy members."

          https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-collection-level-endorsement-policies
          "You can use collection-level endorsement policies to restrict which organization peers can write to the private data collection key namespace, for example to ensure that non-authorized organizations cannot write to a collection, and to have confidence that any state in a private data collection has been endorsed by the required collection organization(s)."

          "If you do not specify a collection-level endorsement policy, the chaincode-level endorsement policy will be applied to protect writes to a private data collection key namespace. This may be desirable if a set of organizations meeting the chaincode-level endorsement policy are authorized to create data in other organization’s private data collection. For example if those organizations are trusted to process transactions but are not authorized to store and later query private data due to industry privacy regulations, or if the private data is being shared or transferred from one set of organizations to another through the use of private data collections. In other scenarios, the private data collection members may need to be in full control of writes to the private data collection, in which case a collection-level endorsement policy should be provided."


          The third reported vulnerability is just something that chaincode authors need to be aware of, which has been added to the Fabric documentation:
          (iii) Exposed ``Payload” field in transaction proposal response.


          https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html#protecting-private-data-responses
          "Chaincode can return any data to a client application in the proposal response payload field. For read-only chaincode functions that query private data and which will not get submitted as transactions to the ordering service, private data may be returned in the proposal response payload field to the requesting client. For chaincode functions that propose private data writes however, take care not to include private data in the proposal response payload field, since this field will get included in the transaction which all channel members can access."

          Similarly, the reported attacks are not possible if the endorsement policies and proposal response payload are used per the documented guidance.


          Thank you,


          Dave Enyeart
          IBM Blockchain

          enyeart@...

          "Wang, Shan" ---03/23/2021 11:17:16 AM---Dear Hyperledger Fabric, We report some of our security analysis of the private data collections (PD

          From:
          "Wang, Shan" <Shan_Wang@...>
          To:
          "security@..." <security@...>
          Cc:
          "Fu, Xinwen" <Xinwen_Fu@...>, Yue Zhang <zyueinfosec@...>, "wangshan@..." <wangshan@...>
          Date:
          03/23/2021 11:17 AM
          Subject:
          [EXTERNAL] Security Analysis of Private Data Collection of Hyperledger Fabric







          Dear Hyperledger Fabric,

          We report some of our security analysis of the private data collections (PDC) to you and attached is a paper systematically presenting a complete security analysis. The paper will be published in July 2021 at the IEEE International Conference on Distributed Computing Systems (ICDCS).

          We believe we have discovered three design flaws on the private data collection in Hyperledger Fabric:
          (i) PDC Non-member peers can endorse PDC transactions;
          (ii) PDC transactions are validated through the same endorsement policy as public data transactions;
          (iii) Exposed ``Payload” field in transaction proposal response.

          We have discovered two classes of attacks against PDC transactions by exploiting the three design flaws:
          (i) Fake PDC results injection attack: malicious peers or clients may disrupt the integrity of the ledger. They may inject a valid transaction with a fake value into the blockchain or write fake values into the PDC in the ledger's world state.
          (ii) PDC leakage issues: the PDC can be revealed to PDC non-member peers and this violates the PDC design principles.

          We have designed defense measures to fix the three design flaws so as to defeat the discovered attacks, and implement these defense measures by modifying the source code of Hyperledger Fabric. Our patches have minor or negligible impact on the system performance.

          More details are presented in the attached paper. Please let us know if you have any questions.


          Best Regards,

          Shan Wang, Southeast University/University of Massachusetts Lowell
          Yue Zhang, Jinan University
          Xinwen Fu, University of Massachusetts Lowell



          (See attached file: Security Analysis of Private Data Collection of Hyperledger Fabric_report.pdf)
--
Brian Behlendorf
General Manager for Blockchain, Healthcare and Identity

bbehlendorf@...
Twitter: @brianbehlendorf

[attachment "Hyperledger_PDC_ICDCS2021_final.pdf" deleted by David Enyeart/Durham/IBM]




Private Chaincode Lab - Tue, 03/30/2021 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Private Chaincode Lab

When:
Tuesday, 30 March 2021
8:00am to 9:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Organizer:
bur@...

Description:
Two of the Hyperleger Labs projects (private data objects and private chain code) are collaborating to develop a "private smart contracts" capability.

Join Zoom Meeting https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Meeting ID: 518 494 7650 Passcode: 475869


Re: calling a methods chaincode from a different method in the same chaincode #fabric-chaincode

Tsvetan Georgiev
 

Hi Malik,

The contract API is used to invoke a chaincode usually deployed as separate instance (could be on the same or different channel).

When you need to call a method inside your chaincode you just call that method instead of using the invoke API.

If you need to have clear separation of the functionalities you better separate them and deploy as different chaincodes. That way you can use the contract API to call a chaincode from a chaincode.

I suggest to go through the following documentation (helps a lot to design properly your chaincodes): https://hyperledger-fabric.readthedocs.io/en/release-2.3/developapps/chaincodenamespace.html



Senofi

Tsvetan Georgiev
Director, Senofi Inc.

438-494-7854 | tsvetan@...

www.senofi.ca

www.consortia.io







---- On Tue, 30 Mar 2021 06:30:43 -0400 Marek Malik <info@...> wrote ----

Hello Guys, 

Just a quick question. 

I have this scenario where I'm calling one method inside a chaincode A (let's say to update some properties based on external factors). Now, these external factors are being returned by a second method inside the same chaincode. I'm trying to call this method using the contract api interface using the Stub (invokeChaincodeWithStringArgs). But I'm getting an error on the execution of that call. Is there any possibility to make such call or there is some limitation and I need to create a new chaincode for that second method?

I have encapsulation inside the chaincode, so the two methods are being executed in two different services that are not linked with each other. I. would like to keep things that way, so if there are some

 






calling a methods chaincode from a different method in the same chaincode #fabric-chaincode

Marek Malik <info@...>
 

Hello Guys, 

Just a quick question. 

I have this scenario where I'm calling one method inside a chaincode A (let's say to update some properties based on external factors). Now, these external factors are being returned by a second method inside the same chaincode. I'm trying to call this method using the contract api interface using the Stub (invokeChaincodeWithStringArgs). But I'm getting an error on the execution of that call. Is there any possibility to make such call or there is some limitation and I need to create a new chaincode for that second method?

I have encapsulation inside the chaincode, so the two methods are being executed in two different services that are not linked with each other. I. would like to keep things that way, so if there are some

 

1761 - 1780 of 11510