Skip to content
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.

Sign up for GitHub

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

Jump to bottom

doc: add minutes for August 8th, 2017 #38

Closed
wants to merge 4 commits into from
Closed

doc: add minutes for August 8th, 2017 #38

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
985dd77
doc: add minutes for August 8th, 2017
sam-github Aug 10, 2017
c44b686
fixup! doc: add minutes for August 8th, 2017
sam-github Aug 21, 2017
9896c6f
squash! address Michael's review
gibfahn Sep 6, 2017
f1dfc58
squash! more dashes
gibfahn Sep 6, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 98 additions & 0 deletions meetings/2017-08-10.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
# Security WG meeting 2017-08-10

- GitHub issue: https://github.com/nodejs/security-wg/issues/32
- Meeting video: N/A
- Previous meeting: https://github.com/nodejs/security-wg/pull/28


# Present

- Josh Brown-White (@joshbw)
- Colin Ihrig (@cjihrig)
- Reed Loden (@reedloden)
- Deian Stefan (@deian)
- Michiel Prins (@michiel3)
- Bryan English (@bengl)
- Devon Rifkin (@drifkin)
- Sam Roberts (@sam-github)

# Review of last meeting

Actions from https://github.com/nodejs/security-wg/blob/ac6623f305002b973011d58f4e2485a0f1e2a0b5/meetings/2017-07-13.md#actions

- [ ] Michael: will document the security release process
- [ ] Michael: will add recurring sec-wg meeting to calendar
- [x] Sam: will schedule the next WG meeting (https://github.com/nodejs/security-wg/issues/32)
- [x] Sam: will look at https://github.com/rubysec/ruby-advisory-db to see how they store vulnerabilities for gems and ruby (see end of file)
- [x] Sam: will PR a description of what Node.js considers a security issue (https://github.com/nodejs/security-wg/issues/18) See https://github.com/nodejs/node/pull/14485
- [x] JoshBW: will evaluate HackerOne and BugCrowd (https://github.com/nodejs/security-wg/issues/16, https://github.com/nodejs/security-wg/issues/17)
- [x] JoshBW: will investigate what it takes to get a semmle.com license for Node.js as an open source project (https://github.com/nodejs/security-wg/issues/29)

# Agenda

## HackerOne Demo

Reed gave a demo of HackerOne’s dashboard. He sent out a bunch of demo
accounts. If you didn’t get an email and would like a demo account please ping
@reedloden (reed @ hackerone.com)

Can’t set an “auto-disclosure” after X days of filings in the settings (though
you can after a bug was resolved), but probably possible with the API.
Normally disclosure requires an intentional act within the report UI.

Full API (https://api.hackerone.com). Probably not a Node.js library for it
yet (Ruby, Python, Go, etc. are present)

Can issue CVEs for both node and npmjs.org packages if we choose to go down
that route.

Two possible use-cases:
1. Node vulnerabilities
2. Npmjs.org package vulnerabilities

For npmjs.org packages, HackerOne looks to have a great feature set, CVE
issuance and the rich permission model among them.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mhdawson this should interest you in particular



I’d like to see some investigation of the API to ensure we can pull issues out
as JSON for storage in github.com, but otherwise I think we should try it out.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that GitHub's security team uses our API to pull content in order to display on https://bounty.github.com/, so it's definitely possible. :)


For node vulnerabilities, we’ll have to pitch HackerOne to the core members of
the Node Security Response Team, Ben and Fyodor at least. The thing they might
find most compelling for use with node core relates to permissions, since the
Response team size has been described as too large recently. Use of HackerOne
will allow:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re: #17 (comment), these are the features that I think will be most interesting to @nodejs/security

- Web or email submission of vulnerabilities, with the submitter being allowed
to view and discuss the submission directly using the web UI.
- The conversation history to be made public when a vulnerability is
publicized: ATM all conversations about vulnerabilities are private for ever,
unnecessarily.
- A triage team of 3 or 4 people who can see every submission, and either
reject it as not a vulnerability, or assign it to the correct people to work on
it further (those people would get access to only the one specific pre-release
vulnerabilty). This would allow, for example, HTTP experts who are not on the
Response team to be brought into the discussion of an HTTP issue. It would also
allow the setup of a team to further triage npmjs.org package vulnerability
reports, so the response team can re-assign non-node core vulnerabilities.

## rubysec organization

- Github: https://github.com/rubysec/ruby-advisory-db
- Stores vuln per file, covers both gems (`gems/`) and ruby runtimes (`rubies`)
- Every vuln has a CVE or a OSVDB, but the OSF (open security foundation) has
closed shop, and all the OSVDB links are now dead
Copy link
Contributor Author

@sam-github sam-github Aug 10, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reedloden this was unfortunate, is there a back story? This shouldn't happen to us if we use mitre-allocated CVEs, I hope.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://blog.osvdb.org/2016/04/05/osvdb-fin/ and http://www.securityweek.com/osvdb-shut-down-permanently talk about it somewhat, but the TL;DR is that the majority of the work was being done by Risk Based Security (with very little input from the community), and then others were scraping the site and taking the content for themselves without paying for it or contributing back. So, frankly, just didn't make financial sense for them to keep running the site. :(

This has no impact on CVE allocation at all. One of the big reasons why RubySec used OSVDB for a long time is because it was so hard to get CVEs from MITRE. Nowadays, with more and more companies being CNAs, that isn't a problem anymore. CNAs receive a block of CVEs from MITRE, so they can just assign on-demand.

- Vuln files are named after the CVE/OSVDB ID, so they must request one for every
submitted vuln. @reedloden of HackerOne manages this process, allocating them
for ruby. It involves filling in a form of basic information, and he offered
to do this for Node.js as well.
- Vuln schema: https://github.com/rubysec/ruby-advisory-db#schema
- Vulns can be submitted via PR, or a form (https://rubysec.com/advisories/new),
but there isn’t any information on what the disclosure policy is. The form
suggests to me that they expect to see only reports for issues that are already
publically known and reported to the gem authors (and possibly already fixed).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reedloden is this true?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, RubySec mostly dealt with tracking existing vulnerabilities that were already fixed (or at least widely-known). Rarely did we ever act as a middle-man with disclosing issues to specific gems, mostly because we would just point people to http://guides.rubygems.org/security/#reporting-security-vulnerabilities (which, now that I read it, is outdated). However, in the Node.js world, I know that NSP has actively acted as that middle-man, which is fine, but it does require coordination work on somebody's part to reach out to the appropriate module author and get issues fixed.

- A tool is included to check for vulnerabilities:
https://github.com/rubysec/bundler-audit
- Has a website: https://rubysec.com/, from which you can get Atom updates of
vulns, browse the DB using a web UI, report vulnerabilities, and it also points
to the bundler audit utility.
- No information on policies or procedures that I found.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reedloden I was looking for information on when vulns would be published, specifically, how gem authors are notified, how long they are given to respond to reports, things like that. Can you elaborate on your experience with this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned above, we generally only deal(t) with already fixed issues, just getting them categorized and publicized so that people would know to update their applications to use the fixed versions. As such, I'm not aware of any set policies/procedures on handling of disclosure. In those rare cases where RubySec did deal with something, we would generally just reach out to the affected gem authors and notify them privately, working with them on getting an issue fixed, and then getting it publicized in ruby-advisory-db so that people knew to update.