Create CVEs for contributed projects in 2024

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.

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

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.

✨ Provide contrib security advisories in OpenSSF Vulnerability format for dependency tracking Active 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
📌 Update CNA scope Needs review on what I would suggest we include in the CNA scope if we keep it.

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

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.

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.

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!

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.

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.

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.

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

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.

Great, thanks for taking a look, mradcliffe!

Updating the issue summary with progress. A ton of comments were left on private issues. 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.

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!

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.

Better status

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.

greggles → credited yesct → .

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.

Oh, and here are the links:

https://www.cve.org/CVERecord?id=CVE-2024-13312
https://www.cve.org/CVERecord?id=CVE-2024-13311
https://www.cve.org/CVERecord?id=CVE-2024-13310
https://www.cve.org/CVERecord?id=CVE-2024-13309
https://www.cve.org/CVERecord?id=CVE-2024-13308
https://www.cve.org/CVERecord?id=CVE-2024-13305
https://www.cve.org/CVERecord?id=CVE-2024-13304
https://www.cve.org/CVERecord?id=CVE-2024-13303
https://www.cve.org/CVERecord?id=CVE-2024-13302
https://www.cve.org/CVERecord?id=CVE-2024-13301
https://www.cve.org/CVERecord?id=CVE-2024-13300
https://www.cve.org/CVERecord?id=CVE-2024-13299
https://www.cve.org/CVERecord?id=CVE-2024-13298
https://www.cve.org/CVERecord?id=CVE-2024-13297
https://www.cve.org/CVERecord?id=CVE-2024-13296
https://www.cve.org/CVERecord?id=CVE-2024-13295
https://www.cve.org/CVERecord?id=CVE-2024-13294
https://www.cve.org/CVERecord?id=CVE-2024-13293
https://www.cve.org/CVERecord?id=CVE-2024-13292
https://www.cve.org/CVERecord?id=CVE-2024-13291
https://www.cve.org/CVERecord?id=CVE-2024-13290
https://www.cve.org/CVERecord?id=CVE-2024-13289
https://www.cve.org/CVERecord?id=CVE-2024-13288
https://www.cve.org/CVERecord?id=CVE-2024-13287
https://www.cve.org/CVERecord?id=CVE-2024-13286
https://www.cve.org/CVERecord?id=CVE-2024-13285
https://www.cve.org/CVERecord?id=CVE-2024-13284
https://www.cve.org/CVERecord?id=CVE-2024-13283
https://www.cve.org/CVERecord?id=CVE-2024-13282
https://www.cve.org/CVERecord?id=CVE-2024-13281
https://www.cve.org/CVERecord?id=CVE-2024-13280
https://www.cve.org/CVERecord?id=CVE-2024-13279
https://www.cve.org/CVERecord?id=CVE-2024-13278
https://www.cve.org/CVERecord?id=CVE-2024-13277
https://www.cve.org/CVERecord?id=CVE-2024-13276
https://www.cve.org/CVERecord?id=CVE-2024-13275
https://www.cve.org/CVERecord?id=CVE-2024-13274
https://www.cve.org/CVERecord?id=CVE-2024-13273
https://www.cve.org/CVERecord?id=CVE-2024-13272
https://www.cve.org/CVERecord?id=CVE-2024-13271
https://www.cve.org/CVERecord?id=CVE-2024-13270
https://www.cve.org/CVERecord?id=CVE-2024-13269
https://www.cve.org/CVERecord?id=CVE-2024-13268
https://www.cve.org/CVERecord?id=CVE-2024-13267
https://www.cve.org/CVERecord?id=CVE-2024-13266
https://www.cve.org/CVERecord?id=CVE-2024-13265
https://www.cve.org/CVERecord?id=CVE-2024-13264
https://www.cve.org/CVERecord?id=CVE-2024-13263
https://www.cve.org/CVERecord?id=CVE-2024-13262
https://www.cve.org/CVERecord?id=CVE-2024-13261
https://www.cve.org/CVERecord?id=CVE-2024-13260
https://www.cve.org/CVERecord?id=CVE-2024-13259
https://www.cve.org/CVERecord?id=CVE-2024-13258
https://www.cve.org/CVERecord?id=CVE-2024-13257
https://www.cve.org/CVERecord?id=CVE-2024-13256
https://www.cve.org/CVERecord?id=CVE-2024-13255
https://www.cve.org/CVERecord?id=CVE-2024-13254
https://www.cve.org/CVERecord?id=CVE-2024-13253
https://www.cve.org/CVERecord?id=CVE-2024-13252
https://www.cve.org/CVERecord?id=CVE-2024-13251
https://www.cve.org/CVERecord?id=CVE-2024-13250
https://www.cve.org/CVERecord?id=CVE-2024-13249
https://www.cve.org/CVERecord?id=CVE-2024-13248
https://www.cve.org/CVERecord?id=CVE-2024-13247
https://www.cve.org/CVERecord?id=CVE-2024-13246
https://www.cve.org/CVERecord?id=CVE-2024-13245
https://www.cve.org/CVERecord?id=CVE-2024-13244
https://www.cve.org/CVERecord?id=CVE-2024-13243
https://www.cve.org/CVERecord?id=CVE-2024-13242
https://www.cve.org/CVERecord?id=CVE-2024-13241
https://www.cve.org/CVERecord?id=CVE-2024-13240
https://www.cve.org/CVERecord?id=CVE-2024-13239
https://www.cve.org/CVERecord?id=CVE-2024-13238
https://www.cve.org/CVERecord?id=CVE-2024-13237

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

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

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

Thanks for the reminder. That's now done.