Security WG Informal Meetings at NINA 2017

[sam-github]

There were three informal meetings of security-wg memembers and interested parties at Node Interactive, October, 2017. This issue is to collect notes on what was discussed. I'll add mine as the first comment, anyone else with notes is free to add theirs, and we can close the issue during the next formal WG meeting.

[sam-github]

These are my notes from discussions over 3 occaisons, a WG dinner the second night, a WG meeting at the collab summit day 1, and part of the open discussion on collab summit day 2 that discussed security group membership.

There was a lot of discussion of what the groups are, and what the processes are. The security groups are:

1. email triage: the people who receive emails to security@nodejs.org from https://nodejs.org/en/security/
2. private security issue tracker: the people who can see https://github.com/nodejs/security/issues
3. private security patch review repo: the people who can see https://github.com/nodejs-private/node-private (there are some people in 2 who are not in 3, its not clear why)
4. trusted thirdparties who receive advance notice of sec vulns and patches: ... this group is proposed, there is no formal method to notify thirdparties though doing so has been discussed during preparation of recent security releases

After reviewing above and the issue flow, we discussed following specific topics.

email triage

• consists of 6 people now: https://github.com/nodejs/email/blob/master/iojs.org/aliases.json#L48-L54
• what is criteria of membership?
  • consistent response
  • availability
  • competence
  • trustworthiness

Nobody voiced any objections to the current 6, or even a need to change them, they are doing a fine job.

Having the existence and responsibilities of the group documented and publicized was requested, as well as some process for joining/removing the group (assumedly the current process would be to ask of the TSC and/or PR the nodejs/email repo, the TSC directly oversee this group's membership).

security team

The team with pre-publish access to the issues after the email report has been copied to the issue tracker.

• @sam-github: proposes that a tool like HackerOne would allow more fine grained control over access. It would allow there to not be a at-nodejs/security team at all, instead there would be only the email triage team (6 people ATM), who would then invite specific relevant nodejs collaborators to have access to a specific issue if they agree to work on that issue and keep its existence private. The system would become need-to-know. See Who should be in @nodejs/security? Who should have access to the private repo? TSC#358 and suggest that security reports handled using a tool other than github's issue tracker TSC#344 for more discussion.

• dan shaw: more interseted in repeatable process than in the actual membership

• @jasnell(on triage team): thinks HackerOne will make triage be easier, incremental change, start using HackerOne with the existing team setups, and iterate

• @drifkin: re a hackerone based process: what is the point of protecting the visibility to the initial report if the patch goes into a repo that a much wider team can see? Suggestion made that perhaps in medium term a new private repo can be made for each issue being patched, and only need-to-know access can be given

• Q: what happens when things stall?

• A: hasn't happened yet, maybe escalate to the TSC?

• Q: when do we make things public?

• A: we can set HackerOne up to make all issues public in 90 days unless someone deliberately decides to extend

thirdparty npm package triage

With Node Foundation wanting to accept reports of thirdparty package vulnerabilities, as opposed to recommending them to be reported to the Node Security Project as is currently being done on our page, https://nodejs.org/en/security/, we will need a triage process and group.

Who should be on this list?

Generally, criteria should be same as for the core triage. There was some discussion of whether having two email addresses or one to report issues is better, and general agreement that people won't distinguish between them very well, and make mistakes, so its probably better for all reports to go to the same group. Either a combined core+thirdparty group, or else for all email reports to go to core, and for them to delegate it to a thirdparty group if its not specific to core (btw, such a system is very easy to implement with HackerOne).

Asked for volunteers with security expertise willing to triage thirdparty vulns, and also willing to do the outreach to thirdparty authors to get bug fixes/responses from them.

@evilpacket says he gets about two reports a week to the node security project, though sometimes someone spams him with the names of every npmjs.org package that uses child_process and reports that as a vuln (for example).

Volunteers:

• vladimir, sqreen
• daniel kluss, ceo@archeofuturus.com, would like to nominate someone
• lance said that redhat might propose someone
• ... did I miss anyone? we probably need a couple more

Some suggested that to shed the load () 15 active would be great, a minimum of 7 active people.

Will need to have a process for publicization, particularly because we cannot guarantee that thirdparty package authors will fix a bug, respond, or even have contact information available.

In the case that we can't reach them, we will publicize after some reasonable time.

If thirdparty responds and if they say its not a sec issue (this is moderately common, even though sometimes sec researchers disagree) then we can just make it public immediately.

what are the privacy expectations for the triage teams?

Needs to be described. There is currently absolutely no written policy for members of teams with pre-release security information.

There was broad agreement for a policy of:

You as an individual cannot disclose even the possible existence of a vuln to anybody outside the team.

There is broad consensus that the process should be documented, and that some kind of record of agremment to the policy be made (sign? PR a repo under the policy? something...).

should there be a downstream consumers sec early access group?

Note: there often is a blog post before saying "heads up, a fix is coming"

Redhat, for example, takes days to get a build out, so if they don't have early
access to the patch, they are guaranteed to have a zero-day for every node
sec release because it takes days to build, they'd really like to get early access.

The board for node (&linux foundation) may be able to help with prior art in how
to set this up, and with legal advice on how to get NDAs, and how to decide who can get early access.

jasnell: this early disclosure program would have to be managed by the foundation,
because its non-technical, this gives legal protection to us, and allows us to avoid any liability
concerns

[lance]

@sam-github just one nit - we could potentially take days to get a release out. But I like to think that our process is smoother and quicker than that. We are still formalizing it, though, and nothing is baked yet. However, even if it only takes a couple of hours, it would be nice to have ahead-of-time awareness so that we can schedule for it and be prepared when the moment comes. And even those several hours are potential attack vectors for applications running on a PaaS.

[mhdawson]

@lance what we have been doing is

1. An announce that binaries will be released for a security fix 1 week ahead of time (unless we don't have enough notice to do taht)

2. Release the binaries on the date identified in the announce.

This should give people 1 week notice that they need to plan for incorporating an update.

Is that what you had in mind ?

[mhdawson]

For example: https://groups.google.com/forum/#!topic/nodejs-sec/FG8glRVxS7Q

We've not been 100% consistent with that as the last one was bundled into the regular 8.x release.

We may want to define that the policy for LTS is that if at all possible we need to stick to the 1 week notice (which is what we try to do anyway)

[lance]

@mhdawson a week's notice is good for prepping things, no doubt. I guess my real concern is that in our cloud environment, for example, we repackage Node.js into an RPM (for various reasons that I can get into if you are interested, but I think that's a bit irrelevant), and then use that RPM for Node applications in deployment.

So, when a new security release is out, we have to scramble to create an RPM, build a docker image that installs/uses this, and deploy it to the cloud. Only after all of this happens can customers update their applications to the new version - usually by simply redeploying the app with a click of a magical UI button.

However, this scramble leaves all of our customers' apps in a vulnerable state until we can get everything through that pipeline. Ideally, we would like to deploy our repackaged version to our cloud environment at the moment a new release is available. This implies that we need access to the patch (we are mirroring the nodejs/node repo) before the new release drops - preferably 48 hours in advance, but that's just a ballpark number.

So that would mean, notice 1 week in advance, access to the patch 2 days in advance, and dropping a new release in our cloud environment coordinated with the timing of the core Node.js release.