Create CVEs for contributed projects in 2024 [#3491985]

I think the best way to do this will be:

Get a google spreadsheet of project name, release time, title of advisory, URL of advisory, vulnerability type created ✅
Anyone can help fill in the CWE and CAPEC values in the spreadsheet - ask for Edit access if you want to help.✅
Comment on all the private issues alerting people to come comment over here with any advice/feedback/etc. ✅
Write a script that creates the output json for those ✅
Post them 🎉

Step 1 could be a query on the DB, or some scripting of the json API, or the views module and some copy/paste.

Documentation on D.o API https://www.drupal.org/drupalorg/docs/apis/rest-and-other-apis

From
https://www.drupal.org/api-d7/node.json?type=sa&sort=created&direction=DESC

The following vulnogram fields could be parsed from the ['list'][ID]

Title `title`
Public at: default to `changed` but should review manually
Problem type - CWE manually with some rules, xss is CWE-79, CSRF is CWE-352
Impacts - CAPEC manually (with some rules?)
Vendor or project: Drupal
Product name: field_project['id'] - https://www.drupal.org/api-d7/node.json?nid=NID then it's in ['list'][0]['title']
Collection URL: from the project json https://www.drupal.org/project/SHORTNAME which is in ['list'][0]['field_project_machine_name']
Repository: from the project json https://git.drupalcode.org/project/SHORTNAME
Versions: manual
Description: [PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]
References: ['url']
Credit: could be automated from parsing HTML in field_sa_fixed_by, field_sa_reported_by, and field_sa_coordinated_by

Comments

Comment #1

5 December 2024 at 14:51

greggles created an issue. See original summary.

Comment #2

cmlara

he/him

commented 5 December 2024 at 18:24

Is this being limited to ones that impact only 10,000 installs or are we opening it up to all contrib SA’s?

Do we have a plan to ping the origonal reporters and maintainers for their comment before publication? The CNA can technically publish without maintainer/reporter approval however I would think we would want to get their feedback for their own issues before publication.

Comment #3

greggles

he/him

English

Denver, Colorado, USA

commented 5 December 2024 at 19:02

Issue summary:

View changes

That seems like a nice thing to at least alert the reporters and maintainers we're doing something and let them help/provide advice/provide feedback.

It also wouldn't take a ton of effort to comment on the private issues and link them to proposed content on this issue.

I'm not sure about the 10,000 installs as a hurdle - do you have thoughts on that?

I think the reason for that in the past was the difficulty in filing CVEs. Some of the changes with the API and how CNAs work have made it a lot easier. Maybe we can do CVEs for all modules? Though I can see how we might not want to do it for modules with tiny usage (one module recently had ~10 sites reported). I don't have a strong opinion on how to handle this right now.

I see it documented at https://www.drupal.org/drupal-security-team/cve-assignment but that's a bit brief and maybe we need to revisit it :)

Comment #4

cmlara

he/him

commented 5 December 2024 at 19:29

Personally: I would like to see all SA’s receive CVE’s regardless of the install count (I especially note that none of my sites phone home and I assume some larger site owners configure similar).

This allows 3rd party tooling to work with our data without D.O. or 3rd parties needing bespoke parsers. This becomes more important the less usages as word of mouth is less likely to inform a site owner of a need to update.

RenovateBot for example is currently unable to track Core and Contrib vulnerabilities due to our lack of CVE’s https://github.com/renovatebot/renovate/discussions/22918#discussioncomm...

This also applies to other parsers such as Gitlab Code Security, Amazon Inspector, Docker Hub’s scanner, etc.

#3410338: Provide all security advisories in OpenSSF Vulnerability format for dependency tracking could also possibly be helped as we would be part of the general data pool and could be aggregated (automatically) by an existing deed source.

As a security engineer: I want to use my existing tools and have it catch the issues.

The 10,000 limit it is also relevant to
#3483282: Update Drupal.org's CNA scope on what I would suggest we include in the CNA scope if we keep it.

Comment #5

greggles

he/him

English

Denver, Colorado, USA

commented 5 December 2024 at 21:14

Issue summary:

View changes

I did some exploration, so adding to the issue summary what I've found from the API.

Comment #6

greggles

he/him

English

Denver, Colorado, USA

commented 9 December 2024 at 21:45

Issue summary:

View changes

OK, here's a spreadsheet with some data that will hopefully help us to get to CWE and CAPEC values for all of these advisories.

Comment #7

cmlara

he/him

commented 9 December 2024 at 22:48

Elephant in the room:
How to deal with the unsupported with known undisclosed vulnerabilities Drupalism?

Outside of Drupal we would publish the vulnerability details the same as we would for a program with a fix.

Would appear to me we have 3 choices:

Publish the vulnerability details at time of marking unsupported to allow publishing a CVE.
Hard code a time limit that unsupported modules must be disclosed to allow a CVE to be generated.
Refuse to publish CVE’s for these modules

Some of this has been lightly discussed in the past (not sure if I ever created an issue for this) however now we are changing the landscape again.

Comment #8

greggles

he/him

English

Denver, Colorado, USA

commented 9 December 2024 at 23:03

Thanks for raising that detail.

Option 2 feels like an OK solution in the short term.

Also, if anyone wants to help assigning CWE and CAPEC in that spreadsheet please request "Edit" access via the google interface. Or you can leave comments here with suggestions of values and I will get them into the spreadsheet.

Thanks!

Comment #9

greggles

he/him

English

Denver, Colorado, USA

commented 9 December 2024 at 23:55

Issue summary:

View changes

Comment #10

greggles

he/him

English

Denver, Colorado, USA

commented 10 December 2024 at 14:29

I started commenting on private issues using this text. Feedback to improve it is welcome.

Hello,

The Drupal Security Team is attempting to create CVEs for advisories issued in 2024. We would appreciate your assistance in this process in a few ways.

We will classify the Problem Type using a CWE https://cwe.mitre.org/ and classify the Impact using a CAPEC from https://capec.mitre.org/data/index.html We will do our best to assign a CWE and CAPEC value. <strong>We would appreciate the help of folks involved in this issue in identifying the right CWE and CAPEC. </strong> You can leave your suggestion as a comment on the <a href="https://www.drupal.org/project/securitydrupalorg/issues/3491985">public issue about this process</a> or as an edit on the spreadsheet linked from that public issue. If you want to help filling in more values in the spreadsheet that would be welcome as well.

We will use the names in the advisory and credit them on the CVE as finder, remediation developer, and coordinator. If you wish for your name to be excluded, you may comment here indicating that preference.

We hope this process will help site owners to maintain their sites AND give more valuable recognition for the work of finding and fixing vulnerabilities.

Thanks!

Also the process to assign CWE and CAPEC is about 25% done though I imagine it will be slower to do the rest than these first few.

Comment #11

greggles

he/him

English

Denver, Colorado, USA

commented 10 December 2024 at 23:45

For the Smartling and Loft Data Grids advisories they had hardcoded/distributed vulnerable libraries that had their own CVEs. I updated those advisories with the relevant CVEs and I think we should not issue new CVEs for those. I deleted them out of the spreadsheet.

I also deleted any PSAs.

Comment #12

nicxvan commented 11 December 2024 at 14:18

I looked through, I think the one for rest views is correct on capec, the one I was considering was https://capec.mitre.org/data/definitions/54.html

I did not dig through CWEs, but reading the one posted looks right.

Comment #13

greggles

he/him

English

Denver, Colorado, USA

commented 11 December 2024 at 15:06

Yes, I think 54 is similar and potentially relevant. Thanks for reviewing!

Comment #14

mradcliffe

he/him

English

commented 11 December 2024 at 20:01

I read CWE-863 and CAPEC-87 and those seem like the closest for the Information Disclosure vulnerability in SA-CONTRIB-2024-034 (freelinking row 42).

I looked through some of the children of the parent CWE-285 and CAPEC-115, but did not see any children that were more specific for Information Disclosure.

Comment #15

greggles

he/him

English

Denver, Colorado, USA

commented 11 December 2024 at 20:40

Great, thanks for taking a look, mradcliffe!

Comment #16

greggles

he/him

English

Denver, Colorado, USA

commented 12 December 2024 at 21:28

Issue summary:

View changes

Updating the issue summary with progress. A ton of comments were left on private issues notifying people who worked on those issues about this effort. A few folks have left feedback there or here about the CWE/CAPEC, which is nice. So far nobody has asked for a change in credit on cve vs the advisory.

I've got a pretty simple php script that creates the json for the CVEs, though it has some limitations that I don't think we're going to get beyond:

The version data in advisories is not super consistent and support for 7.x makes that worse. Therefore the output is not always accurate which will require some manual work in vulnogram and comparing back to the source advisory.
It doesn't create descriptions. My plan is to manually click the "Auto Generate" button in vulnogram.
I haven't yet integrated the CWE/CAPEC spreadsheet data to the process, but that's the last step before outputting all the files.

Comment #17

ronaldtebrake commented 13 December 2024 at 07:42

Just wanted to confirm in here we're happy with the ones provided for Open Social's advisories. Thanks for all the efforts in here!

Comment #18

greggles

he/him

English

Denver, Colorado, USA

commented 16 December 2024 at 16:57

OK!

I think the script is now handling most version strings as well as it can given the source data. I also incorporated the CWE and CAPEC data from the spreadsheet. Feedback on the spreadsheet has slowed down, so we can probably consider that relatively stable.

The script relies on the D7 API on drupal.org which is going away, so I don't think we should try to make this part of the tooling here. The script quality reflects that its a onetime thing that is meant to go away, but feedback is welcome to make it better.

How can you help?

I encourage folks to download the script, run it with php advisory-to-cvejson.php and then review the resulting json either manually or by uploading it to https://vulnogram.github.io/#editor

It's expected that 7.x versions are not valid and will prevent submission in vulnogram until they are manually fixed.

Comment #19

greggles

he/him

English

Denver, Colorado, USA

commented 16 December 2024 at 16:58

Status:

Active

» Needs review

Better status

Comment #20

greggles

he/him

English

Denver, Colorado, USA

commented 17 December 2024 at 19:27

Issue summary:

View changes

It...appears I failed to include the link to the gist in comment #18.

Here is the script to generate cve jsons https://gist.github.com/greggles/e3c525af1790c05b1ff882eee826f0fd

As I said there, php advisory-to-cvejson.php and it will create the jsons. Note that the URLs on line 202/203 need to be manually edited to create all of them, i.e. comment out line 203 to generate the most recent advisories.

Comment #21

9 January 2025 at 20:56

greggles credited yesct.

Comment #22

greggles

he/him

English

Denver, Colorado, USA

commented 9 January 2025 at 20:56

Status:

Needs review

» Fixed

OK. Done! Thanks to everyone for providing your analysis and feedback.

Some deficiencies I noticed in the json generated by this script that may not be worth fixing:
Something is corrupted in special characters like á from https://www.drupal.org/sa-contrib-2024-020
The 7.x versions should be described as "custom" instead of "semver"

I realized I could create the unsupported advisories without CWE and CAPEC by removing those fields from vulnogram (I had read they were optional earlier, but thought maybe vulnogram was going to require it). So I did that.

There are no doubt a small number of instances of inaccurate data in these CVEs compared to their advisories, especially as it relates to version strings and 7.x values. There may also be more appropriate or additional CWE and CAPEC values that we should add.

I'm going to mark this issue as fixed since the initial effort is done.

If anyone notices any inaccurate data in these please open new issues in this queue and I should be able to address them quickly.

Comment #23

greggles

he/him

English

Denver, Colorado, USA

commented 9 January 2025 at 20:58

Oh, and here are the links:

Comment #24

nicxvan commented 9 January 2025 at 22:19

Thanks! https://www.cve.org/CVERecord?id=CVE-2024-13254

Comment #25

23 January 2025 at 22:24

Status:

Fixed

» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Comment #26

nicxvan commented 11 February 2025 at 21:57

Comment #27

cmlara

he/him

commented 20 February 2025 at 07:36

Is there an issue to load these CVE ID's into the Security Advisories?

Comment #28

greggles

he/him

English

Denver, Colorado, USA

commented 20 February 2025 at 20:10

Thanks for the reminder. That's now done.

Create CVEs for contributed projects in 2024

Comments

Comment #1

Comment #2

Comment #3

Comment #4

Comment #5

Comment #6

Comment #7

Comment #8

Comment #9

Comment #10

Comment #11

Comment #12

Comment #13

Comment #14

Comment #15

Comment #16

Comment #17

Comment #18

How can you help?

Comment #19

Comment #20

Comment #21

Comment #22

Comment #23

Comment #24

Comment #25

Comment #26

Comment #27

Comment #28

Related issues

Referenced by

News items

Our community

Documentation

Drupal code base

Governance of community