Create a cve for diff

Here's a start on the cve request for diff https://www.drupal.org/sa-contrib-2024-042 →

I think this is CAPEC-113 https://capec.mitre.org/data/definitions/113.html

It's likely also other impacts.

I read some more about CVSS so I could make a more accurate score for this.

Here's a new file.

To review this it may be helpful for folks to

1. download the attachments,
2. rename to ".json"
3. go to https://vulnogram.github.io/#editor and click the
4. Click the "open" button and open the file
5. Review the interface - be sure to hover over different areas of the tool as it has explanations and help built in that is available as a hover state

CWE-200 is discouraged for CVE mapping per https://cwe.mitre.org/data/definitions/200.html and should be avoided if at all possible.

Looking at just the SA without reading the fix code to me the issue sounds closer to CWE-862 or CWE-863 if we want to go under the 200 scope (200 -> 285 -> 862 || 863)

CAPEC-113: Feels a a bit off, it looks to be aimed more at API's (either software or hardware implemented) and a bit more aimed to exploiting them (I'm more thinking SQL Injection or similar) . I wonder if CAPEC-212 might be a slightly better fit? Specifically by leveraging functionality with design flaws that enables the adversary to gain access to unauthorized, sensitive data. since this uses the UI that already exists and its a design flaw that the user can select two points and see the differences between them without filtering. I'm not as well rounded on the CAPEC list and could be mistaken here.

Regarding credit for 'others' that the DST lists as 'Coordinated By' (different from the CVE definition of response coordinator) . While this does appear to be technically valid per the definition given in https://cveproject.github.io/cve-schema/schema/docs/#oneOf_i0_containers... I wonder if it is well aligned to industry practices to list to credit those who are performing their normal duties as part of the CVE process?

I looked through the CVE's for 2023 and 2024 YTD and only found the following references to "other"

CVE-2023-0669:-- Appear to be credit for media publicity.
CVE-2023-24477: Acknowledging an organization that confirmed the bug after report from a customer.
CVE-2023-37895: Unknown reason, both individuals are listed as committers on the Apache Project page.
CVE-2024-29732: The advisory notes discovered by reporter with special thanks to the individual listed as 'other'. Quick glance the individual appear to be a penetration tester. I was not able to link them as staff of the advisory organization.

Is this a trend we want to set when no other CNA appears to do so?

Thanks for those suggestions, research, and advice. The more I get into this the less I see opportunities for mapping and automation, but I also don't think it will be possible to have module maintainers fill it in during the creation of the advisory.

I do think CWE-863 is a more accurate description of the situation. I imagine that we'll get to a point where there are ~10 different CWE entries we end up using and it will be easier to pick among them.

CAPEC-212 also seems like a good fit for this situation.

Thanks for that research about mapping coordinated by. I do think it's important to acknowledge all the work that goes into the process. If we exclude folks who were "performing their normal duties" then isn't fixing a bug in the code a normal duty of a maintainer? And for security researchers I would also say that reporting a bug to the vendor is also the normal duty. That doesn't seem like the right hurdle to use to judge the situation.

From that documentation you linked, here are the allowed values from that page. I can't seem to find descriptions for when to use or not use each of them.
"finder"
"reporter"
"analyst"
"coordinator"
"remediation developer"
"remediation reviewer"
"remediation verifier"
"tool"
"sponsor"
"other"

I think coordinator is a good map - I'm not sure why I missed that in my work so far. What do you think?

The UI has a lot packed into collapses sections. You can click on “type” and “read more” where you will be provided a more detailed description.

Type or role of the entity being credited (optional). finder: identifies the vulnerability.
reporter: notifies the vendor of the vulnerability to a CNA.
analyst: validates the vulnerability to ensure accuracy or severity.
coordinator: facilitates the coordinated response process.
remediation developer: prepares a code change or other remediation plans.
remediation reviewer: reviews vulnerability remediation plans or code changes for effectiveness and completeness.
remediation verifier: tests and verifies the vulnerability or its remediation.
tool: names of tools used in vulnerability discovery or identification.
sponsor: supports the vulnerability identification or remediation activities.

I can see how 'coordinator' could be argued to be the correct classification, and perhaps it is just me, however I perceive the “coordinator” position as being more involved. I envision the role as a person that is actively managing timelines and the developers, checking on them every few days to see how code is progressing, interfacing with the vulnerability reporter as a single point of contact to all internal team members, cross coordinating with the internal QA team, essentially a project manager. I can not speak to this specific SA, only in general, that my experience is the DST is generally not that active in issues which is what raised the question in my mind initially.

If we exclude folks who were "performing their normal duties" then isn't fixing a bug in the code a normal duty of a maintainer? And for security researchers I would also say that reporting a bug to the vendor is also the normal duty. That doesn't seem like the right hurdle to use to judge the situation.

Advisory publication is primarily a low effort administrative duty compared to a developer that must envision the solution and implement it, or a reporter that expended technical effort in discovering and analyzing the fault, as well as choosing to publicize the fault rather than sell the fault.

I can not speak to the Diff issue as I was not a participate to it. My personal experience with the Drupal Security Team is they tend to fill a role analogous to the power company keeping my office on the grid, my ISP keeping the backbone online, and the systems engineer that keeps my email server online to receive messages from the reporter. Critical roles that need to be fulfilled for me as a developer to perform my dustiness, and yet we would not consider crediting them on the security advisory. "Performing their normal duties" is meant simply as a shorthand for "it is expected, it is common, it is not exceptionally note worthy as it relates to this specific vulnerability report", we need the DST members to perform their role to publish the advisory, it is a critical position, and yet at the same time it is the entire reason for the DST to exist making it not noteworthy.

I maintain that following the Drupalism of "credit everyone for everything no matter how insignificant" would degrade the acknowledgment the 'credits' section gives which is disrespectful to the reporter and the fixer.

I see opportunities for mapping and automation, but I also don't think it will be possible to have module maintainers fill it in during the creation of the advisory…
I imagine that we'll get to a point where there are ~10 different CWE entries we end up using and it will be easier to pick among them.

There certainly is a fair amount of variability to it. Yes we will likely get to a point of common mappings for routine issues that we pull from.

Long term, Maintainers should be able to understand the classifications. These identifiers are as much about classifying what the vulnerability is as they are about educating maintainers to constantly evaluate code for common flaws before those flaws ever make it into the repository.

I’ll note that this is much harder to classify when working off the public report vs actually being the developer who created the fix. Significant context is not included in the advisory as written that would help narrow down exact classification which is part of the reason I gave two options in #5 as the correct of the two depends upon internal detail I do not have.

I will also note that these mappings are not a required field for CVE’s. The inclusion is appreciated and with time we can build up maintainers to have the knowledge to include this context without assistance.

I want to focus in on confirming the required fields and how we'd handle them:

1. CVE ID: We'll get this dynamic value each time, so this is covered.
2. Title: I propose we use the current SA title, with some extra info. For core it says "Drupal core" but for other projects I think we could say "Drupal module" or "Drupal theme".
3. Public At: SA published date
4. Problem type: the CWE
5. Impacts: the CAPEC
6. Vendor or project: Drupal.org?
7. Product name: either Drupal core or "Drupal X [module|theme|distribution]"
8. Platforms: I propose we skip this for now since it's rarely relevant.
9. Package collection URL: Link to the project page
10. Source repository: a link to the repo, e.g. https://git.drupalcode.org/project/diff
11. Modules, components or features: again, I think we could leave this blank
12. Source-code file: blank, as generally multiple files are involved
13. Versions: filled in as best we can map them
14. Description: we can auto-generate this.
15. References: the advisory URL
16. Skip Metrics (CVSS) for now
17. Solution: "Upgrade to a version that is not affected. View referenced advisory for more details."
18. Credits: map existing credits (noting cmlara's comment #7 for some ideas on this)

In addition to the fields I propose skipping, we should also skip any field I didn't mention for now. We can edit the records after the fact, so if we want to start adding more information that's always an option. I'd rather we start this work with some information missing than create a big initial and ongoing burden that is not sustainable.

I opened 📌 Create CVEs for Active for the 2 core advisories so far this year as well.

Here ere are some high level thoughts on #9:

I will note if there is ever any question on how to handle these fields https://github.com/CVEProject/cvelistV5/ is an official copy of the CVE database that we can observe to get an idea how other CNA's handle these values to help guide us in interpreting the official definitions.

Skip Metrics (CVSS) for now

I would like to encourage us to avoid skipping the CVSS if possible. Especially if we publish under the new modern V4. The supplemental metrics are an incredibly useful to help site owners determine how to prioritize their time on the vulnerability.

At a minimal we should include the D.O. score as an "OTHER" type.

Solution: "Upgrade to a version that is not affected. View referenced advisory for more details."

Any reason not to include the upgrade to versions and other relevant content here by default? We already generate this as part of creating a Drupal Security advisory, no original thought required to include this.

CVE data is a reference set for security tools, whatever we place her may be visually shown to the site owner when using automated tooling to deploy fixes (helping them determine if the automated fix is sufficient or if they need to take additional action).

Vendor or project: Drupal
Product name: either Drupal core or "Drupal X [module|theme|distribution]"
Package collection URL: Link to the project page

Lets get some definitions from Vulnogram out first (as shown in the UI):

Instruction: Enter a vendor and product OR a package and a collection
Vendor or project; Vendor or org or project
Product name: Name of the affected products
Package or Collection url: URL identifying a package collection (determines meaning of packageName). Example given: https://www.wordpress.org/plugins. 
Package name: Name or identifier of the affected software package as used in the software collection.

However in conflict to the instructions, the CVE schema says product+vendor is mandatory.

Pulling the CVE Schema definition which is more authoritative:

Vendor: Name of the organization, project, community, individual, or user that created or maintains this product or hosted service. Can be 'N/A' if none of those apply. When collectionURL and packageName are used, this field may optionally represent the user or account within the package collection associated with the package.
Product: Name of the affected product.

Contrib modules are generally not created by Drupal as a vendor, and they are not part of the Drupal project (this is Drupal core only), they are independent of Drupal as an organization and are only part of the Drupal Ecosystem.

I would suggest that for Vendor we:
If a (single) company is primarily responsible for the project (such as commerce) we list the vendor name.
If a single individual is primarily responsible for the project we use their name.
If no single vendor or user we consider either using the project owner account name, or we use N/A.

Package or collection url: We do not have a single url to search all project types (module/theme/etc) we could create a single landing page or just use D.O homepage. I would suggest we consider the Drupal Packaging repository url. If we use the packages server URL we can be deterministic about which versions to avoid overlaps. Eg 7.x-1.0 is published as 1.0.0 on the 7.x endpoint which is not the same as 8.x-1.0 which also is published as 1.0.0 on the 8.x endpoint.

Note: the Schema examples do list just "https://drupal.org", however to my knowledge we are not bound to use that.

For me the deciding factor for the collection URL is do we want to be able to show a difference between overlapping versions and provide the information for security scanning software to differentiate the two. I would say yes and that pushes me towards the repo url. If we don't care about differentiating (see the history on why FrinedsOfPhp can't publish Drupal advisories) a fallback to just https://drupal.org/ appears reasonable at the risk of making this harder for automated tools.

Package name: I suggest we use the machine_name (identifier), project names can be changed and will not stay relevant in perpetuity, the machine_name leaves no doubt as to the CVE target identity, it also pairs well if we use the packagist server as that is where the project metadata will be found.

Thanks for that feedback.

Contrib modules are generally not created by Drupal as a vendor, and they are not part of the Drupal project (this is Drupal core only), they are independent of Drupal as an organization and are only part of the Drupal Ecosystem.

The mapping of the concept of vendor from the world of for-profit proprietary software to open source community has always felt problematic to me.

If a Drupal module is hosted and distributed from a 3rd party site and wishes to issue a CVE then it makes sense to me for them to use their own name as vendor.

However, for modules hosted on drupal.org it seems reasonable for the "vendor" to match the place they are hosted/distributed and the name of the community of collaborators (whether corporate, individual, or a mix).

This should have been at "Needs review" status since about #2.

Lots of great discussion here and it was created first. However, I think this should be marked as a duplicate of 📌 Create CVEs for contributed projects in 2024 Active since that's where a lot more work is happening.