Large-scale disclosure guidelines

[ievans]

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!

[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! :)

[sam-github]

Despite new Buffer() being deprecated in newer versions of Node (since 2016), is it still something the NSWG wants disclosed?

Yes. Even though its deprecated, its still in use, and its usage is not decreasing with time (according to @ChALkeR's survey of packages on npmjs.com). IMO, without increasing pressure, its not going to decrease, and we'll never be able to remove the vulnerable API.

[sam-github]

A question about this.

new Buffer has initialized memory since 8.0.0, according to https://nodejs.org/api/buffer.html#buffer_buffer_from_buffer_alloc_and_buffer_allocunsafe

@ievans The problems you are discovering then, are they specific to node versions that are no longer supported? Or do they exploit the difference between number and string arguments passed as an arg to new Buffer(arg)?

[sam-github]

See nodejs/node#27298

[sam-github]

Discussed at #541 , removing from agenda (but please add back if it should be discussed again).

[sam-github]

@ievans are you still interested in this, or should we close it?