CVE Request for Webform Multiple File

Thanks aangel. Moving status. And let's give this a few days for review.

Hi why there is link to security private issue? should not remain private? https://security.drupal.org/node/162249

Question:
It appears from the description the vulnerability was in a 3rd party product that was copied into the the module.

Would the module hosted on D.O. actually be the supplier of the vulnerable product in this case?

Would section 4.3 of the CNA v4.1.0 rules come into play here?

4.3.2 If a CNA is considering an assignment, and the CNA is not the Supplier of the vulnerable Product, then the CNA SHOULD make a reasonable and good faith effort to notify the Supplier. For example, if an operating system Supplier discovers a Vulnerability in a library from an upstream Supplier, in addition to assigning the CVE ID to the upstream Vulnerability, the operating system Supplier SHOULD attempt to notify the upstream library Supplier. This reduces duplicate CVE ID assignments and helps alert others that may be affected by the Vulnerability.

This is an interesting grey area, I'm not 100% sure on this one way or the other, bringing this up for discussion since Drupal actively publishing CVE's is a relatively new development and the procedures appear to be still being developed.

@cmlara thanks for that question and pasting the documentation. Are you interested in contacting the upstream maintainer there?

Or is anyone else interested in doing that? Since the forked code was/is distributed from drupal.org it seems we could issue a CVE if the upstream maintainer is not interested in doing that.

My apologies, I had thought I had submitted my response on this issue previously.

Are you interested in contacting the upstream maintainer there

My entire knowledge of this reported vulnerability is based off the vulnogram, ideally someone who knows more or has been involved in working on the repair to the Webform Multi File Upload module would do so as they would likely be better informed.

it seems we could issue a CVE if the upstream maintainer is not interested in doing that

.

Possibly there are other parts of the CNA rules to consider as well:

4.2.1.1 The CNA with the most appropriate scope MUST be contacted and given the first opportunity to assign.

4.2.1.2 also comes into play that if the most appropriate scope refuses the Root CNA must make a determination and direct a CNA to issue.

then an appropriate Root MUST make a Vulnerability determination. If the Root determines that one or more Vulnerabilities exist, the Root MUST direct a CNA-LR or another CNA with appropriate scope to assign as quickly as possible and no later than 72 hours after becoming aware of the first refusal.

Question is, who is most appropriate scope?

4.2.2.1.3 scope determination is relevant to review.
Drupal.org CNA scope is “All projects hosted under drupal.org, including End of Life (EOL) code.”

What is the interpretation of hosted? Is it being the official development platform, or is redistributing also hosting?
How integrated is the code in the Drupal module (is it line for line, or is it a fork that deviated some time in the past and could legitimately called its own project)?
Is there another CNA with better scope?

I’ll note the goal behind the process is that for any single vulnerability there is only a single CVE to refer to it no matter who re-distributes the code and that any program that contains the flaw references that CVE. All of the above questions are above my current knowledge on the module and how the code was distributed.

OK. I posted https://github.com/fyneworks/multifile/issues/113

Leaving this at "needs review" for feedback on the CVE content although probably "postponed" would be appropriate since we're waiting here on action in that Github project before taking action here.