Security-wg: Node.js ecosystem Bug Bounty program - questions from researcher point of view

[bl4de]

Hi,

NOTE: I've sent those questions earlier to [email protected], but Rod Vagg explained that this email address is for security issues only and adviced to put my questions here. I hope you don't mind :)

First of all - I want to thank you for a great work you do maintaining this program on HackerOne. It's a real pleasure to work with you Guys.

There are couple of questions about the program I want to ask (after first two weeks spent on and 10 reports opened so far):

Communication with Triage team

Is there any way of communicating with you if I will have question(s)/doubts/concerns about issues I find? Slack/IRC? I don't want to mess up in every single report opened on H1 with stupid questions I can just ask on Slack or somewhere I can get response immediately. Examples: configuration settings, dependency packages versions causes that PoC does not work (logs, npm ls output and so on)

If not and/or you just want to keep all information in the report on H1 - that's perfectly fine.

Module age; maintainer activity

Are there any restrictions about how old module is/when last update was done? There are plenty of modules in npm registry published even 4, 5 or 6 years ago. Probably maintainers don't even remember that they published them :D

If there is no active maintainer - is there any chance issue will be fixed by someone else?

The problem is that I've noticed that some of those modules are still downloaded hundreds of times per month. That means if there is a vulnerability - there are still users exposed to them.

Issue root cause - module itself or dependency (eg. outdated)?

How about vulnerabilities caused by outdated modules?

Take a look at https://hackerone.com/reports/309641

The root cause of this vulnerability is outdated connect middleware rather than the module itself.
I am aware of the fact, that Sencha might not be interested in fixing vulnerability in 4 years old file (Connect 2.10.0) .

From the other point of view - existence of such modules like reported in 309641, which is still downloaded ~650 times/month - is a fact. That means about 7000 downloads of vulnerable package during the whole year.

So - question - what should be reported here: vulnerability in the package which uses outdated dependency; OR - vulnerability in outdated dependency?

Module popularity

Last, but not least - so far I was digging mostly around less popular modules, with approx. 500 to 1000 downloads per month. However, I've seen modules with eg. 10 downloads per month. Is it worth your work to report vulnerabilities in such modules?

This is somehow related to Question 2 - so maybe to summarize it up:

How old and how many downloads per month module has to have to be considered as something worth to report vulnerability (my work) and manage fix (your work) ?

Anything else?

Also, is there anything I should know and i am not aware of to do the best in Node.js ecosystem program?

I am going to spend some time to work on this program (I work full time as Fullstack/JavaScript dev and I am using Node and npm ecosystem on a daily basis and it's some kind of natural for me to merge both "worlds" (Dev and Sec) together :)
But also I respect your time you have to spend on each report, so I don't want to bring unnecessary noise to the program and keep level of 'Informative', 'Needs more info' or 'N/A' as low as possible.

Best Regards,

Rafal 'bl4de' Janicki

[vdeturckheim]

Hey @bl4de,

First thanks a lot for your investment in keeping Node.js ecosystem safe. Working with you is awesome for us too!

I will try to answer as much as possible but since our ecosystem security program is still pretty new there are a lot of topics we are still figuring out.

Communication with Triage team

That's a good point. I would not mind having a slack org or an IRC channel dedicated to ecosystem security where the triage team can be reached privately. However, as of right now, I think HackerOne should remain our main communication vector. When the triage team will grow (and I hope it will since we have more and more reports to handle), the need for such platform might get stronger.

Module age; maintainer activity

As of today, we do not have any rules regarding this. I would be tempted to say that our main goal should be to have the vulnerability fixed and if we can't reach it, disclosing the vulnerability is the good thing to do for the ecosystem.

That being said, it seems that we will definitely need to grow our team in order to handle reports.

Issue root cause - module itself or dependency (eg. outdated)?

I have no definitive answer here. I would be tempted to say that we should try to go to the cause of the vuln, therefore report the module that is actually vulnerable. However sometimes, responsibility might be hard to point. Maybe module A is vulnerable because it uses module B in a way that was not designed by module B maintainer (we would not blame fs for directory traversals).

At the end of the day, until we get a definitive policy, I'd say it will be the call of the people involved in the report handling.

Module popularity

As we do not fix modules ourselves, our job is mainly triaging reports and applying the process. I believe that, to be coherent with my previous responses, I must answer that everything on npm is in the scope of our work with no impact coming from package's popularity.

Anything else?

I will use this space for my conclusion. I feel I was not very good at providing definitive answers here but this is linked to the current state of our program.

By browsing this repository, you will learn everything regarding the history of our initiative and pretty much everything we already discussed on that topic.

I really love your enthusiasm in helping us making the ecosystem safer. All your future reports will be warmly welcomed.

Your questions in this issue will probably start a few new discussions here (at least I hope) and I'd love you to stay around to help us figuring out what's best!

[bl4de]

Hi @vdeturckheim,

Thank you very much for your feedback!

Best Regards,

bl4de