Large-scale disclosure guidelines

Hello! My name is Isaac and I work with a small group called R2C. We’re writing JavaScript analysis tools and one of our projects is inspired by @ChALkeR’s work to find new Buffer() vulnerabilities. Our analyzer is context-aware and has found more undisclosed vulnerabilities lurking in the long-tail of npm packages. I’m reaching out to get the NSWG’s thoughts and help after talking with @vdeturckheim and @reedloden earlier this month.

1. Despite new Buffer() being deprecated in newer versions of Node (since 2016), is it still something the NSWG wants disclosed?
2. If there are a large number of disclosures, what are the best practices for disclosure through NSWG?
3. Have large scale disclosures been done before that we can learn from?
4. Do you have recommendations for people or other communities that might be interested helping us triage our findings and disclose to NSWG? We may be interested in sponsoring work or supporting bounties.

@vdeturckheim suggested we might chat about this at the next working group meeting. Looking forward to your thoughts!

[ievans]

@sam-github We haven’t had as much time to work on this recently, but we are still interested and I was just talking about it to @ChALkeR a few hours ago. There was some confusion and I missed the NSWG meeting where it was discussed, but I would be interested in discussing it more broadly!

To answer your question and @lirantal (sorry for delay! my github notifications are very overwhelmed):

• @sam-github : yes, the buffer issue was fixed in Node.js 8.0.0, so these problems are not relevant to new versions of Node (except for those who ported to explicitly use the new allocUnsafe API). We look for instances where the Buffer API is definitely used with a number or with a value that could be a number or of some other type.
• @lirantal there are on the order of thousands if you trawl through the long tail of packages

[lirantal]

👋@ievans wonderful to hear about this initiative

My input:

1. Is the analyzer specifically designed for buffer findings or are we talking about broader support for other deprecated or older APIs?
2. What size is “large”? if it’s tens I think this can probably be accommodated through the WG.
3. I believe Vladimir was the person who handled a large scale of prototype pollution attacks a while back (about I think 40 of them) but if I’m not mistaken it took quite a long time to make this happen and we might need HackerOne’s help with submitting multiple reports, but you’d still need to submit them one by one, with a dedicated report for each module impacted.
4. Snyk has been known to work in the past with academic researchers in order to disclose a large mass of vulnerabilities in the open and co-ordinate all of the disclosure process (some references are Liang Gong’s disclosure of hundreds of path traversals and Jamie’s Davis’s work around redos vulns). Full disclosure: I work at Snyk, and would like to think we’re very community and open source oriented so there isn’t any commercial message here, but since you asked about other resources I saw fit to suggest this route too.

Happy you’re bringing this up, let’s chat indeed in the next agenda call! 😃