Create CVEs for

This is a better status, I think.

This got a +1 from larowlan in a separate discussion.

If there's no more questions/comments I plan to make them, so adjusting to RTBC.

If there's feedback we can edit after they are created.

Classifying as a child of 📌 Create CVEs for Active as it requested a CVE for SA-CORE-2024-001 (and SA-CORE-2024-002 was not yet public at the time of that issue creation).

I haven't had time to sit in depth on these, however looking just at 2024-002 an obvious discrepancy is that it indicates only 10.2.0-10.2.9 are vulnerable while D.O. indicates it is >=10.0.0<10.2.10

I am a bit concerned about how overly simplistic and uninformative the messaging is.

Looking at 2024-002

A vulnerability in Drupal Core allows File Manipulation.

Whats impacted? what compoents? what do I need to worry about? (Rember when a site is using CVE tools they will see the CVE data not the refrences links)

Compared to the D.O. text:
Under certain uncommon site configurations, a bug in the CKEditor 5 module can cause some image uploads to move the entire webroot to a different location on the file system.
This tells me what I need to know, that it is in CKEditor 5, and that the issue is my server webroot will be moved. It allows me to easily identify if I have been impacted by this vulnerability in the past (or in the future) without needing to reference data sources outside the the CVE.

A CVE is intended to be informative on its own.

CNA V4.0:
5.2: Description: Through automation efforts such as the CVE Record Format and CVE Services, the content of the prose description in a CVE record is becoming less important. The prose description is still useful in providing sufficient information to uniquely identify the Vulnerability and distinguish it from similar Vulnerabilities.
5.2.1 (A CVE description) MUST summarize the Vulnerability, using, for example, information from 5.1.1 through
5.1.7.
5.1.1 (A CVE record) SHOULD contain sufficient information to uniquely identify the Vulnerability and distinguish it from similar Vulnerabilities.

While 5.1.1 is not a 'must' do we feel we know better than the CNA program to ignore something they say we should do?

Hmm, for the descriptions I attempted to follow the suggested template. I don't think it makes sense to copy and paste the description from the SA and duplicate the content (both from a SEO perspective and on general principle).

While 5.1.1 is not a 'must' do we feel we know better than the CNA program to ignore something they say we should do?

I am very confident I don't know more than the program administrators about how to write a good CVE.

My biggest concern is the sustainability of this work. It seems important to get the key parts done: creation of all 2024 CVEs, and then making it part of ongoing operations. THEN I'm willing to consider ideas that add more work.

My biggest concern is the sustainability of this work

Technically speaking, long term isn’t trying to create two separate descriptions less maintainable than creating one single? Unless our current SA’s fail to meet the minimum specifications it seems like it would be more effort not less. I’m not saying our current descriptions on D.O. are perfect as is, just that to me they align closer to what the goal should be compared to the current text.

Long term: how often do we edit SA’s after publication that we need to worry about extra effort on duplication?

• 2024-001 and 2024-002 show no edits since publication day.
• 2023-006 only edit since publication day was to add the CVE ID.
• 2023-005 has a single non visible edit
• 2023-004 has no edit since publication
• 2023-003 has one edit to convert an individuals first name to their user name.
• 2023-002 and 2023-001: no edits since publication day

I don't think it makes sense to copy and paste the description from the SA and duplicate the content (both from a SEO perspective and on general principle).

SEO probably should not be a concern, if we show up first great, however if not the CVE program is well respected, we should not need to be concerned about them possible being higher in rankings than us. The entire point of CVE’s is to distribute information, who gives that information is secondary to the information being distributed.

As for general principle, I’m not sure what we would consider the principal reason? For me the CVE’s job is to distribute the information.

CNA v4.0 5.3.3.4 (a cve record must have at least one public reference that) MUST provide the minimum information required to support the content of the CVE Record.

We inherently must have some level of duplication as the CVE must contain content and that content must be supported (duplicated/expanded upon) by the reference material.

I attempted to follow the suggested template

This is going to be CNA v4.0 5.2.8, the description may follow key phrasing described in https://www.cve.org/Resources/General/Key-Details-Phrasing.pdf

Default Template on Vulnogram:
Note: playing with the Generate button it appears the generates text is always a set format and changing the template has no impact (at least on a mobile Safari browser).
[PROBLEMTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] on [PLATFORMS] allows [ATTACKER] to [IMPACT] via [VECTOR]

Key Phrasing doc has an additional default template:

[COMPONENT] in [VENDOR] [PRODUCT] [VERSION] [ROOT CAUSE], which allows [ATTACKER] to [IMPACT] via [VECTOR].

Vs what we this issue proposes publishing:
A vulnerability in Drupal Core allows File Manipulation.<p>This issue affects Drupal Core: from 10.2.0 before 10.2.10.</p>

I see Problem Type, vendor/product, version in the proposed text.
I do not see component, platforms (maybe not useful as discussed in other issue), attackers, impact, vector or root cause.

Definitions (from key phrasing doc):
Vector – The inputs and/or processes required to exploit the vulnerability
Component – Part of the product– Trigger point – The part of the product where the error occurs (may be multiple places)– Interaction point – The part of the product that accepts the vectors– Neither are a requirement. You can skip them if there is no information for them.

Skill building Exercise:
The key phrasing doc contains examples text for XSS and SQL
Injections perhaps grab one of our older Security advisories that is a XSS or SQL Injection, write it up as you believe it should be then compare it to what the Key Phrasing guide shows? This might help identify where information is either not being copied or doesn’t exist in D.O. SA’s (I have made a point a number of times that I believe our advisories under report) related to uniquely identifying the vulnerability.

Had some time to sit down with Vulnogram.

I'm not sure however it appears it is using CAPECS as the 'vector' with the 'attackers' phraseology before it ' (may have to go look at Vulnograms source code next).

The Key Phrasing doc does make note that "Vector phrasing tends to vary by flaw type" which Vulnogram does not appear to have the ability to take into account. I would opinine we could keep the basics there, however we should expand upon them as noted under reporting causes issues in ensuring a precise match. System Admins will be looking through lists and see just the descriptions, if they have a page of CVE's that say the exact same text it would be near impossible to determine which CVE is which without excessive detailed drill down (especially since we are not populating the source code files portion of the CVE).

At this point I probably need to sit through several of https://www.youtube.com/playlist?list=PLWfD9RQVdJ6ecSMwikUGf6_7YIkoTkWZp to see if they go in more depth as to what exactly the CNA program is promoting as ideal, always possible I'm behind the times and they are wishing for less detailed reports and its only the 'old guard' of CVE writers who refuse to change.

A key point here is that Vulnogram is just a tool, we don't need it to fit our desired design perfectly, ideally this is going to be done by automated means 📌 Automate publishing of CVE's Active however Vulnogram can help inform what that syntax looks like.

Quick note on Suggested changes for 2024-002, Check with the DST private tracker however I looking at the source code fix I believe it fits better under:
CWE-1173 Improper Use of Validation Framework
CAPEC-153 Input Data Manipulation
CAPEC-212 Functionality Misuse

The existing CWE-703 is discouraged use, and based on the fix I do not believe it is a file manipulation (at least based on how I was able to reproduce the vulnerability in a lab, though perhaps I found a second vector path to the same flaw).

I happened to see this vulnerability in Apache Tomcat today.

CVE https://www.cve.org/CVERecord?id=CVE-2024-52318

Description is:

Incorrect object recycling and reuse vulnerability in Apache Tomcat. This issue affects Apache Tomcat: 11.0.0, 10.1.31, 9.0.96. Users are recommended to upgrade to version 11.0.1, 10.1.32 or 9.0.97, which fixes the issue.

And it links to a mail thread at https://lists.apache.org/thread/co243cw1nlh6p521c5265cm839wkqdp9

Which includes this extra detail

The fix for improvement 69333 [0] caused pooled JSP tags not to be
released after use which in turn could cause output of some tags not to
escaped as expected. This unescaped output could lead to XSS.

It seems helpful to see what other projects are including in CVEs.

It seems helpful to see what other projects are including in CVEs.

Reasonable to do.

https://www.cvedetails.com/vulnerability-list/published_since-2023-11-18... provides a reasonable interface to see recent CVE's along with the issuing CNA name. (Feel free to use whatever tool works best for you.)

On a cursory glance I see variance across the spectrum, and even see variance inside the same CNA, likely due to the advisory being written by different maintainers.

Looking at the recent ones I did see a number related to our 'neighbor' ecosystem Wordpress published through Wordfence and Patchstack both publishing CVE's (note Patchstack also publishes for non Wordpress applications). Wordfence tends to go in depth on the description and link to references, Pathstack description includes the absolute bare minimal and every one I clicked on linked back to themselves with no additional details.

For context the Apache CNA reports also appear to show variance

Here's a prior core cve from 2023 https://cveawg.mitre.org/api/cve/CVE-2023-31250 for comparison.

In #11 you said

perhaps I found a second vector path to the same flaw

Could you file that in the private tracker?

I looked at the nature of 002 for the CWE and would say it's more like https://cwe.mitre.org/data/definitions/390.html I agree 1173 could also fit.

For CAPEC:
https://capec.mitre.org/data/definitions/165.html
https://capec.mitre.org/data/definitions/153.html
https://capec.mitre.org/data/definitions/212.html

I don't have a strong feeling about the mapping of the CAPEC. I think 165 fits pretty accurately.

Attaching some updated jsons.

I didn't realize the status was at needs work, so setting back to RTBC. The points in #8 are educational, but I don't think they move these to needs work.

Thanks for all the work that's gone into this.

I think SA-CORE-2024-001 might map more closely to CWE-400 than CWE-405.

It looks like 405 relates to amplification (e.g. sending a small message to a DNS server which results in it sending a large response).

400 is about exhausting resources such as memory, which I think is more aligned with the core issue in this case.

SA-CORE-2024-002 was such a weird edge case that I don't know if we'll find perfect categories for it, but CWE-390 and CAPEC-165 both look like a pretty good match.

+1

Thanks for those thoughts, mcdruid. 400 is a "discouraged" value, while 405 is Allowed. Looking further, I wonder if CWE-1050 - CWE-1050: Excessive Platform Resource Consumption within a Loop might be more accurate than even 405?

Ah okay, sorry I missed that.

How about CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')?

Not vastly different to 1050, but IIRC an infinite loop was pretty much the issue in 001, and it looks like 835 is "allowed" (if I'm looking at the right field).

Yes, I agree 835 is a more accurate characterization of 001. Thanks for finding that.

I've now posted these as https://www.cve.org/CVERecord?id=CVE-2024-11942 and https://www.cve.org/CVERecord?id=CVE-2024-11941

I plan to turn my focus to the next core advisories for 2024 and after that to all the contrib advisories for 2024.

The issues for that work are here:
📌 Create CVEs for SA-CORE-2024-003, 004, 005, 006, 007, 008 Active
📌 Create CVEs for contributed projects in 2024 Active

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