New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] Early disclosure program #68

Open
vdeturckheim opened this Issue Nov 12, 2017 · 8 comments

Comments

Projects
None yet
7 participants
@vdeturckheim
Member

vdeturckheim commented Nov 12, 2017

As discussed in last WG meeting and based on @jasnell issue regarding an early disclosure program for vulnerabilities in Node.js core. We would like to collect opinions from potential users of such initiative:

In other term, if you or an organization you are involved with would want to have access of such an early disclosure program, please explain here what you would need such program to be.

For instance, a cloud provider might want to have access to patched binaries of Node.js before their public disclosure in order to provide protection to their clients as soon as possible.

Please let us know how we can build something relevant for you.

Also, please feel free to advertise this issue to anyone who might be interested in providing feedback on this topic.

@wzrdtales

This comment has been minimized.

Show comment
Hide comment
@wzrdtales

wzrdtales Nov 13, 2017

For us it would be, give us a platform where we configure a webhook which sends us information on early disclosure, including the following:

  • Are the issues fixed critical?
  • Has been touched a larger part of the logic or just a small change? This will decide if it goes to a manual review or not.
  • The url to the new binaries
  • PGP signing of the new binaries (the pgp signer should be known beforehand and should be officially stated somewhere)
  • The (upcoming) CVE reference
  • Description of the issues fixed

This would be quite enough, whenever possible including this into the process of automating the process of patching vulnerable pieces of software we enjoy when we don't need to poll this information, but get called instead. This would be the perfect solution for us at least :)

wzrdtales commented Nov 13, 2017

For us it would be, give us a platform where we configure a webhook which sends us information on early disclosure, including the following:

  • Are the issues fixed critical?
  • Has been touched a larger part of the logic or just a small change? This will decide if it goes to a manual review or not.
  • The url to the new binaries
  • PGP signing of the new binaries (the pgp signer should be known beforehand and should be officially stated somewhere)
  • The (upcoming) CVE reference
  • Description of the issues fixed

This would be quite enough, whenever possible including this into the process of automating the process of patching vulnerable pieces of software we enjoy when we don't need to poll this information, but get called instead. This would be the perfect solution for us at least :)

@mhdawson

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson Nov 16, 2017

Member

IBM's customers use both the IBM SDK for Node.js as well as community binaries. In terms of an early access program it would best allow us to serve these customers if we could get the patches in advance so that we can incorporate them into the IBM SDK for Node.js such that it could be released on the same day as the community binaries are released.

Member

mhdawson commented Nov 16, 2017

IBM's customers use both the IBM SDK for Node.js as well as community binaries. In terms of an early access program it would best allow us to serve these customers if we could get the patches in advance so that we can incorporate them into the IBM SDK for Node.js such that it could be released on the same day as the community binaries are released.

@brycebaril

This comment has been minimized.

Show comment
Hide comment
@brycebaril

brycebaril Dec 2, 2017

Member

At NodeSource we have the a scenario very similar to the one @mhdawson outlined. Advanced availability allows us time to address any conflicts and still release expediently after the community binaries to reduce exposure to our customers.

Member

brycebaril commented Dec 2, 2017

At NodeSource we have the a scenario very similar to the one @mhdawson outlined. Advanced availability allows us time to address any conflicts and still release expediently after the community binaries to reduce exposure to our customers.

@ofrobots

This comment has been minimized.

Show comment
Hide comment
@ofrobots

ofrobots Jan 8, 2018

For Google Cloud, the early access program would allow us to do testing and release patches expediently after community binaries.

ofrobots commented Jan 8, 2018

For Google Cloud, the early access program would allow us to do testing and release patches expediently after community binaries.

@joshbw

This comment has been minimized.

Show comment
Hide comment
@joshbw

joshbw Jan 22, 2018

Sorry for the delay in this thread - I chatted with the various folks in Azure around what info they in general they prefer to have when planning engineering work around patches. Generally, the following are quite helpful:

  1. Date/time the patch is expected to be made available, so Azure can plan for it. Is there an advanced time for some AND general availability, and if so, what are the conditions around the advanced patch (just for testing/prep for general availability, or does it allow early patching)?

  2. Versions of Software being impacted (e.g. is this a problem just for current, or just for LTSB, or both?)

  3. Does it only impact the software on a specific platform (x86 vs x86-64, Linux vs. windows, etc.)

  4. Severity/ nature of issue being addressed, so azure knows how to prioritize and what actions may be called for (e.g. should they immediately patch and cycle all customer instances to make sure they are covered as soon as possible, or is it something Azure could hold off on until off peak hours per region)

  5. Whether/when Azure can give their customers notice of a reboot should it be something that justifies immediate disruptive action

  6. Regression risks, disruption risks (e.g. did an API behavior change? Is it likely to cause noticeable perf issues and if so in what context, etc.)

  7. Are there mitigating actions distinct from the patch that either can, or should also be taken.

  8. Are there clear, enforced repercussions for violating any embargoes (i.e. no need to worry about other participants zero-daying with the info, because they will get suspended from the program for some period of time)

Some things that are immediately apparent is that while a good deal of this info is clearly useful when making engineering decisions around a patch, much of it is also super helpful for adversaries if they were to get advanced notice (for example, if a specific API is being deprecated in a security patch, that gives a really good indicator where the problem is). If we were to make most or all of this info available to major consumers of Node in advance I think that would clearly require a criteria for who gets advanced access (just cloud providers? how is that defined? Platforms and OSes too?), and an NDA (not just generally, but specifically one that lays out how the info can be shared internally at these orgs. For example, sharing with Azure would not necessarily allow the Azure team to notify all of the teams using Electron at MS that they should patch).

joshbw commented Jan 22, 2018

Sorry for the delay in this thread - I chatted with the various folks in Azure around what info they in general they prefer to have when planning engineering work around patches. Generally, the following are quite helpful:

  1. Date/time the patch is expected to be made available, so Azure can plan for it. Is there an advanced time for some AND general availability, and if so, what are the conditions around the advanced patch (just for testing/prep for general availability, or does it allow early patching)?

  2. Versions of Software being impacted (e.g. is this a problem just for current, or just for LTSB, or both?)

  3. Does it only impact the software on a specific platform (x86 vs x86-64, Linux vs. windows, etc.)

  4. Severity/ nature of issue being addressed, so azure knows how to prioritize and what actions may be called for (e.g. should they immediately patch and cycle all customer instances to make sure they are covered as soon as possible, or is it something Azure could hold off on until off peak hours per region)

  5. Whether/when Azure can give their customers notice of a reboot should it be something that justifies immediate disruptive action

  6. Regression risks, disruption risks (e.g. did an API behavior change? Is it likely to cause noticeable perf issues and if so in what context, etc.)

  7. Are there mitigating actions distinct from the patch that either can, or should also be taken.

  8. Are there clear, enforced repercussions for violating any embargoes (i.e. no need to worry about other participants zero-daying with the info, because they will get suspended from the program for some period of time)

Some things that are immediately apparent is that while a good deal of this info is clearly useful when making engineering decisions around a patch, much of it is also super helpful for adversaries if they were to get advanced notice (for example, if a specific API is being deprecated in a security patch, that gives a really good indicator where the problem is). If we were to make most or all of this info available to major consumers of Node in advance I think that would clearly require a criteria for who gets advanced access (just cloud providers? how is that defined? Platforms and OSes too?), and an NDA (not just generally, but specifically one that lays out how the info can be shared internally at these orgs. For example, sharing with Azure would not necessarily allow the Azure team to notify all of the teams using Electron at MS that they should patch).

@vdeturckheim

This comment has been minimized.

Show comment
Hide comment
@vdeturckheim

vdeturckheim Feb 22, 2018

Member

Let's find a champion regarding this.

Member

vdeturckheim commented Feb 22, 2018

Let's find a champion regarding this.

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Mar 22, 2018

Contributor

@mhdawson is there anything to discuss for this issue today? If not, can you remove the security-wg-agenda label until there is (it's been there since November 2017).

Contributor

cjihrig commented Mar 22, 2018

@mhdawson is there anything to discuss for this issue today? If not, can you remove the security-wg-agenda label until there is (it's been there since November 2017).

@mhdawson

This comment has been minimized.

Show comment
Hide comment
@mhdawson

mhdawson Mar 22, 2018

Member

Agreed, will remove and we can put back on once we make some progress.

Member

mhdawson commented Mar 22, 2018

Agreed, will remove and we can put back on once we make some progress.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment