🇺🇸United States @greggles

Maybe the best short-term answer here is not to show anything.

In the long run it seems great if we could do the recursive calculating you mention, catch, and then have icons/text to explain "all modules are covered with stable releases" or "It's a mix of statuses and stable releases, get details."

It seems important to show the coverage before the modules are installed on a site. The status is pretty prominent on the project page to help people make informed choices.

Thanks for the thoughts in #10.

I'm inclined to take small steps here and see how the process of updating it this time goes before we make a big change to the scope. Most of the other organization scopes I reviewed have rather brief and broad scope statements, so I'm hesitant to enshrine too much of the project's practices into the scope.

I guess a good system would be to revisit this periodically (every year or so?) to ensure it matches the current practices.

The issue summary says:

Nginx is one of the most popular web servers on which Drupal is run.

Does anyone have data about the level of popularity?

I think comment #10 got flagged by the d.o auto moderation system. I've published it and confirmed nitinpatil's account so that won't happen again. Welcome nitinpatil and thanks for your comment on this issue!

The concept of the check for CSP header on the status page feels a like a pretty big additional functionality for core. It seems like something security_review could handle, so I filed ✨ Check for CSP on private and public SVG files Active to track it there.

greggles → created an issue.

larowlan → credited greggles → .

Some other questions to consider - I've added numbers to them to facilitate discussion.

1 Could the .htaccess change interfere with the use of typical
theme-provided SVGs?

Great question. I don't think it's very common for svgs to use these features (I've only seen it once on a non-Drupal mapping site) but it made me realize the change could be inside of the htaccess for the files directory and therefore only apply to a subset of files. That feels like it reduces the risk this change will negatively impact while still retaining most of the value in protecting sites from malicious files. I asked mr.baileys and he agreed on that idea, but we could certainly discuss it more.

2 Do SVGs pose risks for users outside of an http request, eg when downloading them and viewing them? This risk of course exists with other file types, but less so for jpg/png images.

I think they do pose a risk, but solving it feels like a separate problem to me. I filed ✨ Filter SVGs before uploading by default Postponed and linked it to this as related for followup that could address this risk. The situation today is that site admins are enabling SVG uploads on their site often and there is no protection for a variety of risks that creates. This issue attempts to solve one of the risks (XSS), but is not a complete protection against all risks.

3 Are typical XML-issues such as XXE, XSLT a possible issue, if so, in what contexts?

As far as I understand those risks they are not relevant on a typical Drupal site and would only be relevant on sites that parse the XML of the SVG file. These changes don't affect that for better/worse.

* Are we sure all possible threats from SVGs in img/object/background contexts are tackled? Which specs apply?

I'm not sure this mitigates all possible threats (several additional threats are mentioned in this issue already). I'm sure the change in this issue is progress in securing sites against cross site scripting, but not a solution to all risks of SVG files.

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.

Creating this as a postponed followup to #2868079: Add a default Content-Security-Policy-header for svg files → to provide a more robust solution to a wider set of problems.

greggles → created an issue.

MR is green again and I addressed the feedback in #65.

Thanks for your thoughts, gapple, and setting back to RTBC.

I forgot to mention I confirmed this is the header used by github for svgs content they serve.

I agree with gapple's comments that the change to all private binaryresponses could be broken out to another issue and we would still have most of the value in this issue.

I did some more manual testing and realized that the previous rule allowed `malicious.sVg` to bypass the protection. I updated the htaccess rule to be case insensitive. I've now manually confirmed this protection works on public and private svg files.

Thanks for the feedback, @larowlan. I accepted the one suggested change.

The proposed new header for all private files was introduced by gapple (CSP maintainer) so it feels pretty likely to be widely acceptable.

Thanks @phenaproxima!

mr.baileys and I are doing another round of testing and will ping others to get more eyes on the security component of this.

Better status

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.

Thanks, alexpott. I did a bit more of an update to the issue summary to make it more of a focused summary of the conversation and current status.

There's currently a failing test and I'm unsure if it's related or what the cause is.

I added change records as suggested in #54. Thanks for the review!

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.

updating link and language from provisional toward onboarding

Backporting to 10.x can be a followup, IMO, so I removed the web.config from the issue summary.

Consider adding warning to image fields when people allow SVGs to be uploaded.

It seems better for this issue to ship the CSP and consider that good enough. I removed the idea bout labels from the issue summary as well.

There were some test fails.

The core.services.yml definition needed to be updated after 📌 Add default autoconfigure to all *.services.yml and remove event_subscriber tags Fixed .
Since this issue is about updating the htaccess we also need to update the scaffold htaccess.

The other test fails didn't look related to me, but I'm not sure.

Tried to address the feedback from the bot in #48.

If #2868079: Add a default Content-Security-Policy-header for svg files → happens then that should get rolled into these recipes as well.

This seems like a highly valuable feature before Drupal CMS 1.0 ships, so bumping priority.

Issues that will be packaged in a security releases and advisories are worked on in private. Working on this in public was agreed which means there will be no advisory nor security release.

The question of whether it needs CR? Not sure personally.

Great, thanks for taking a look, mradcliffe!

greggles → credited greggles → .

IMO this is a critical bug, so adjusting priority.

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

I think we could consider providing OpenSSF format in addition to CVE. However, the CVE process has gotten a bit easier since the slack thread linked in 2022.

There are now CVEs for all of core issues for 2024.
I'm working through contrib for 2024 in 📌 Create CVEs for contributed projects in 2024 Active .

I'd love help on those to the extent folks can do it. Ping on slack or those issues if you're interested in helping.

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.

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 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.

noting the limit of 50 items per page in the limit section.

I guess I should link to the CVEs:

https://www.cve.org/CVERecord?id=CVE-2024-12393 SA-CORE-2024-003
https://www.cve.org/CVERecord?id=CVE-2024-55634 SA-CORE-2024-004
https://www.cve.org/CVERecord?id=CVE-2024-55635 SA-CORE-2024-005
https://www.cve.org/CVERecord?id=CVE-2024-55636 SA-CORE-2024-006
https://www.cve.org/CVERecord?id=CVE-2024-55637 SA-CORE-2024-007
https://www.cve.org/CVERecord?id=CVE-2024-55638 SA-CORE-2024-008

OK, I published these and updated the advisories to include the CVE number.

Up next is 📌 Create CVEs for contributed projects in 2024 Active .

If there's any proposed necessary edits to these feel free to comment with them, though my priority personally is on getting all of 2024 filed.

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!

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.

Has this situation come up again?

It seems uncommon enough that more documentation is not warranted.

Do you have some example scenarios to add?

I think we could say that XSS is CI:Some/II:Some.

What else?

Sorry for the delay. This is now fixed along with a few other fixups nearby.

This seems oudated/not necessary.

Feel free to reopen if you feel it's still necessary.

OK, here's new files for 003, 006, 007, 008 fixing the title on 003 and the CWE on 6, 7, 8 and also an accidental duplicated "Drupal Drupal Core" in 006.

915 makes sense to me, thanks for reviewing these and finding that.

2 adjustments:
* fixing title on 003
* changing the gadget chains to 915

Other than that I think these are ready to go.

005 is pretty easy if we just accept the same values as 003 for CWE and CAPEC.

For the 3 gadget chains, the problem type and impact seem like they should be
https://cwe.mitre.org/data/definitions/502.html CWE-502: Deserialization of Untrusted Data
https://capec.mitre.org/data/definitions/586.html CAPEC-586: Object Injection

This is all of them, so moving to "Needs Review"

Just realized I left the title as default, so need to change that on 003 before creating it.

For 004, I think CWE should be
https://cwe.mitre.org/data/definitions/178.html Improper Handling of Case Sensitivity
AND https://cwe.mitre.org/data/definitions/289.html Authentication Bypass by Alternate Name
And the CAPEC should be https://capec.mitre.org/data/definitions/233.html Privilege Escalation

I created a default json for core.

And here's a start for sa-core-2024-003. I think

It seems for xss we can make them CWE 79. There are several CAPEC to choose from, including 63 XSS, 591 reflected XSS, 588 DOM based XSS, and 592 stored XSS. I chose just 79 and 63 for 003.

+1 to the proposed resolutions.

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

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

I think this is not a reasonable, practical, or helpful idea. Maintainers and reporters are generally overwhelmed with the information and process required in creating a security fix. We should seek to strip away parts of that process rather than adding more.

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

greggles → created an issue.

greggles → created an issue.

Regarding #4: Looking at https://www.drupal.org/psa-2024-06-26 → and especially at https://www.drupal.org/psa-2022-06-20 → I do think it's the responsibility of individual sites to update their dependencies.

Can you explain more why you think it's the responsibility of the maintainers to bump the version?

LGTM. Thanks.

Great, thanks trackleft2. +1 from me. @joegraduate should have permission to add you and I think that's an appropriate thing to do as a co-maintainer :)

mr.baileys → credited greggles → .

mr.baileys → credited greggles → .

damienmckenna → credited greggles → .

I added you, joegraduate. Thanks for offering! I think other folks from #3 could be added as well, ideally after a comment here. If University of Arizona is committed to using and maintaining the module then adding them could make sense to help with any staff transitions. That seems less necessary here than it does if this were like a University of Arizona specific base theme.

+1 from me.

joegraduate helped with testing of ✨ Disable or customize expiration email Needs work already.

I'd like to leave this open for a smidge in case another maintainer has thoughts, but moving it to RTBC as I think that's the next step.

Please reopen if your interest renews.

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?

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.

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.

moar updates

Updating for 2024

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

greggles → credited greggles → .

setting it again to be sure

If folks want to read they can.

It looks to me like this was merged/fixed across several branches, so marking it fixed is the right status.

It was fixed in 7.x-2.x and not backported, so we can use this status which is a little better.

Following.

As far as I know, the Drupal CMS project does not change expectations about what it means when a maintainr opts into security coverage or does/doesn't make a stable releases.

publishing

greggles → credited greggles → .

removing outdated note. adding relevant doc for db drivers

heine → credited greggles → .

page status is ok

Adding a title

adding the documentation

xjm → credited greggles → .

xjm → credited greggles → .

greggles → credited greggles → .

I completed the survey.

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.

ptmkenny → credited greggles → .

I've also granted you rlhawk the right to add and remove maintainers. Perhaps I could transfer the entire project to you (not sure how though) ?

I think edit the project node and set rlhawk as the author. I believe you have access to do that.

In the last 2 weeks there were a few dozen messages. I guess gmail spam filtering handles that volume pretty well?

I'd also be fine with it getting deleted and sending an 'address not found' error response. As I hinted in the issue summary and mentioned in slack, this gets an extremely low volume of legitimate mail (I can't remember when the last real mail was - it was years ago, maybe a decade ago). The list archives seem corrupted, but seem to confirm several years of the last 10 it did not have any messages https://lists.drupal.org/mailman/private/security-press/

greggles → credited greggles → .

poker10 → credited greggles → .

greggles → created an issue.

Maybe we're caught on word choice then?

It seems like avpaderno you would like to see a main process and a set of allowable exceptions, while I think catch and I are advocating for the main process to include several options (one is the current process, one is having a history of significant contributions to major projects including core).

I think it's fine to have some people reviewing and approving applications under the main process (avpaderno, sounds like you are happy to keep doing that) while others (e.g. catch) are interested in reviewing and approving applications under the exceptions.

I think it makes sense whether main process or exceptions for their to always be a documented issue for the change in roles.

Updating the title to focus on the problem first.