Publication of CVE-2024-45440 by MITRE

@cmlara,

I think I can help you with the first concern on how it went and how it could be prevented in the future. I've reported the vulnerability to the DST around 4 months ago. After some discussion it became clear that it needs to be solved in public by the DST. So I've created a public issue for this and asked if a Security Advisory needed to be created for this. Where the DST answered with: "No security advisory is needed for public issues."

Since it was now public and the DST would not create a SA, I've asked MITRE if it was possible to assign a CVE-ID to this issue. In this case MITRE answered with: "The Drupal security team is
allowed to assign a CVE ID even if the issue can be solved in public. We cannot take any further action at MITRE unless you establish that
the Drupal security team will not assign a CVE ID."

So I've went back to the DST and I've asked if a CVE-ID could be created for this issue. Where the answer was: "Sorry, we are not issuing CVEs for issues which are allowed to be fixed publicly and does not have security advisories."

So I think your first concern is answered that this was published by MITRE as the CNA Last Resort (CNA-LR) due to refusal by an approved CNA to publish a valid security concern.

I hope this helps

@senscybersecurity
Thank you for the follow up, and additionally thank you for following appropriate steps to work with the DST on responsible coordinated disclosure and assignment of a CVE followed by utilizing the dispute process to continue escalating this issue.

I appreciate your efforts on this.

Sadly CNA's failing to issue CVE's for valid vulnerabilities does happen.

DST and D.O. Community:
I hope as an ecosystem we can use this as an example to understand that the policies of the Drupal Ecosystem do not absolve us of responsibility to properly report vulnerabilities to the community.

Silent fixes do not help us maintain a secure ecosystem.

I know I have "ruffled some feathers" over the past few years with suggestions and concerns about our existing policies. I hope we can use this incident as a stepping stone to improve the D.O ecosystem and improve our security posture going forward.

I agree that 🐛 Maintenance pages leak sensitive environment information. Needs review is a bug, but disagree that it's a security vulnerability.

The report relies on someone mis-configuring their site, to the point where every single request to that site would generate a PHP warning, flooding their logs. This is not really much different to someone enabling the 'verbose' error level in production and just showing all errors on every page, which core provides as a configuration option in the UI - that would also be a site mis-configuration rather than a security issue in core.

If we look at the examples on https://owasp.org/www-community/attacks/Full_Path_Disclosure, they rely on an attacker crafting URLs to an otherwise 'working' site in order to produce the error. A properly configured Drupal site will not do this, it will only do so if you configure settings.php to result in a PHP warning on every request.

With 🐛 Maintenance pages leak sensitive environment information. Needs review in public, it is easy for people to provide fixes for it and review them, without having to be members of the security team. Although I will note that the person who provided an MR for that issue was me, before I engaged in this meta discussion about whether it should be public or not, and not the person who opened the meta-discussion complaining why it wasn't fixed in private instead.

If someone wanted to improve Drupal security, they could work on issues with the 'security improvements' tag, which that issue has had since July ( https://www.drupal.org/project/issues/search?issue_tags=Security%20impro... → )

There are different incentives which don't necessarily align very well when it comes to publishing SAs and/or CVEs.

For a researcher / reporter getting a SA/CVE published can be quite desirable; it's arguably part of the currency of that ecosystem and it's definitely understandable that it can be disappointing if the decision is made not to publish an advisory and to handle an issue in the public queue instead.

On the other hand, https://www.drupal.org/psa-2023-07-12 → mentions some of the benefits of handling certain issues in the public queues. Foremost is that bugs can often be fixed more quickly and with more scrutiny / testing in public than is practical in private.

I am not an expert in MITRE's processes for issuing a CVE "over the head" of a CNA. However, I do know that typically there's very little (if any) validation of the technical aspects of reports made to MITRE, with the unfortunate consequence that there are a lot CVEs in the system that have little or no technical validity. There are several where the report was rejected as invalid by the upstream project maintainers, and these are of questionable benefit to anyone other than the researchers who got to list the CVE on their resume/CV. MITRE is not in a position to be able to judge the technical merits of specific reports.

If the overall aim of the Drupal Security Team is to keep Drupal and its users secure, and there are limited and finite resources available to do this work, it makes sense to "deflect" issues / reports which do not represent a real security risk to Drupal sites to the public queue, especially if the alternative is for lower priority bugs to languish in a private tracker.

If MITRE decides that it will issue CVEs for Drupal issues when the Drupal Security Team - as the CNA for the project - has decided doing so would not be appropriate, I don't know that there's much that the Drupal Security Team can do about that, other than discuss the matter with MITRE and ask that they not do this in future.

Who would benefit if the Drupal Security Team started to issue SAs/CVEs for reports that had been judged as "can be handled in public"? The researcher gets the reward for their work, but does the overall Drupal community benefit?

(I am definitely not trying to be judgemental about researchers wanting to get the tangible recognition for their work; I have been in that position myself several times and certainly understand the incentives.)

How would we expect individual sites to handle SAs for issues that were deemed as appropriate to handle in public? There's already a maintenance burden with keeping up with security releases for SAs which were judged as severe enough to warrant handling in private. How would sites decide whether they should prioritise updates that were fixed in public but got an SA? Presumably the SA would only be published once the fix was committed?

.. the policies of the Drupal Ecosystem do not absolve us of responsibility to properly report vulnerabilities to the community.

Silent fixes do not help us maintain a secure ecosystem.

There will always be a "grey area" as to whether certain bugs do represent a vulnerability, however I don't think it makes sense to argue that all issues that might be labelled as "security improvements / hardenings" should get an SA/CVE. Doing so would arguably "debase the currency" from the point of view of someone maintaining a Drupal application that has to decide how to prioritise what and when to update.

Letting lower priority fixes sit neglected in a private issue tracker doesn't benefit anyone. Setting deadlines on those so that the researcher resorts to "full disclosure" isn't really much different to the issues being marked as "can be handled in public", depending on your point of view.

If the issue really is important to fix, that can be expedited in the public queue. If the details are made public and there's little activity, is it really a high priority bug? Who would benefit from added fanfare around those?

The report relies on someone mis-configuring their site, to the point where every single request to that site would generate a PHP warning, flooding their logs.

I want to dedicate this single post to look at this aspect of CVE's. The point of CVE's is to provide information to product users so that they can evaluate for themselves the risks involved with a 'vulnerability'.

Switching hats from security researcher to system admin:
On the face of the CVE the amove statement is correct If we are talking about my "single fronted statically configured site" (basically the 'single developer special') for this to happen would generate a significant amount of errors and breaking portions of the site.

However this CVE actually tells me so much more than just the literal example given. As a sysadmin I take a step back and realize the CVE essentially says "When the hash file is unreadable the full path to the file will be leaked"

Depending upon what environments I am in this simple description tells me different possible ways this can occur that only I can know and only I can calculate the "Impact Factor" for this flaw.

A few example environment and their risk factors of this that are not a simple 'misconfiguration' impacting every request:

Mutli-frontend with a weighted load balance, secondary server missing the file:
How the file is missing is a provisioning fault, This point goes more to directly discuss the risk that this would be 'clearly' visible. This may actually only impact a fraction of my connections. As a 'extremely simplified' example assume 2 frontend deployment with a 75% weight to Node A, a systems admin will only see this in 25% of logs. It becomes much more likely this may be 'missed' Scale up the number of frontends to 10, and the risk becomes even higher and the ability to notice becomes lower. Especially since it appears this does not 'degrade' the site in the traditional sense making it less likely the healthcheck will pull the frontend from rotation.

Using a Secrets Managements Solution to write the hash file:
In environments with a secrets management solution its possible that errors can occur with the software. The file does not normally exist in the environment and requires the solution to be written. Errors or bugs could lead to the file being deleted intermittently, For sake of numbers lets say that it impacts only 1% of my connections per month. It is not unheard of to site site owners respond with "Well its fixed now we can look if it occurs again" (We have even seen D.O. infra respond to issues this way).

Secret file is on a SAN/NAS/etc:
Intermittent stack issues could lead to the vast majority of the time this file is accessible and only a fraction of the time does the path leak. The operating system disk cache is a great help in this case, however that is only a temporary savior. Eventually disk errors may populate up

CVE's are written with enough information to understand what the cause is and to give information to evaluate the risk. The overly simplified version for CVE is much less likely to happen, however it does not change the root fact that the flaw exists and could leak data. Each of the above 'more complicated' deployments increase the risk of the fault occurring and decreases the probability of the fault being detected.

To be clear, I'm not saying Drupal is at fault in these scenarios for those external systems failing, just that this , like many vulnerabilities, is not a clear "happens when a site owner makes a configuration error that impacts every single request" and is exactly why CVE's jobs are to communicate the flaw existence even if the majority of users will never be impacted. The CVE is for those of us who will be impacted.

Switching to my incident response team hat:

Normally I'm not one to be as worried about paths, that said this particular path is a 'step up' as it reveals where 'secret' information is stored. This is a file to be protected. An attacker having the path does not make me immediately vulnerable, however it is a step towards an attacker being able to bypass my security controls. As an example disk access monitoring, a process that goes straight to a single file is much less likely to trigger an alarm than a process scanning my drive looking for files. Having the path could let an attacker gain an edge.

I'm sure the next retort will be is "No one is going to spend that amount of time on an attack" for those of you who run sites that this is true, absolutely you can dismiss these types of CVE's as unimportant I have sites that fall into this category that I would likely not even bat an eye on this particular incident. On the other hand I also have sites that are under attack from the same adversaries for years, on these sites I have a much different view on the risks of a full path data leak, I don't view keeping the path secret as magically making me safe, I do however view it as 'extra help I do not need to give the attackers to allow my security the best chance at success".

Small events such as this 'add up', for those familiar with the Swiss Cheese Model, any single one of these issues not being present may prevent a successful attack, incidents happen when every step breaks down, not when a single step fails, that however is exactly what makes a single step failure important to be known, to avoid breaking down 'too many' barriers. Security Advisories/CVE's are the Security Industry method to communicate those 'break downs' in the system so that we can close up these holes.

I don't think many people would argue with the suggestion that CVE is a far from perfect system.

Drupal Security Advisories are not perfect either.

CVSS scoring has its problems, as does the risk calc. that the Drupal Security Team uses.

There have been multiple proposals to replace CVE with something better, and as laudable as those efforts are, https://xkcd.com/927/ comes to mind.

The swiss cheese metaphor makes sense in many cases; it's illustrative of the ideas of "defense in depth" and "chaining attacks" etc..

I cannot speak for all stakeholders in the Drupal community, but I personally do not believe that it would be an improvement for those that manage Drupal sites to receive a significantly increased volume of security alerts (where the delta would mostly be issues that have been judged as lower priority) which they have to evaluate and triage.

To my mind part of the job of the Drupal Security Team is to evaluate the severity and applicability of submitted vulnerabilities in order to filter out some of the noise and only present Drupal site owners that subscribe to the feeds of Security Advisories with alerts that are worthy of their time and attention.

This is always a balancing act.

When SAs are published, the team is often asked "how bad is this?" / "how urgently do we need to patch?" / "am I affected if I only use X?" etc.. It's another balancing act to include relevant contextual information including details of potential mitigations etc.. in the SA without spelling out the steps to exploit a vulnerability for potential attackers.

Any highly security conscious site owners who wish to subscribe to the full fire-hose of any and all potentially security adjacent information could keep an eye on all d.o issues tagged with "security improvement".

If that's not a sufficiently high-fidelity way to solve that use case, the community could come up with other conventions / workflows.

(editing broken img)

I am attempting to avoid editorializing in this post with reservation of editorial comments for a followup.

For the context here are the latest CNA rules that the DST agrees to adhere to as a registered CNA:
https://www.cve.org/ResourcesSupport/AllResources/CNARules

Here is a bit of details on what changed between 3.x and 4.x of CNA rules.
https://www.cve.org/Media/News/item/blog/2024/05/07/CNA-Rules-v4-0-Updat...

A Webinar of the new 4.0 rules is available here:
CNA Rules v4.0 Q&A Webinar →

Section 4 is likely of most interest for these discussions, however it is best to read the entire document for best context.

4.1 CVE identifies technical, cybersecurity Vulnerabilities. The CVE Program Glossary defines a Vulnerability as:
An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.

4.1.2 Conditions or behaviors that do not lead to a security impact SHOULD NOT be determined to be Vulnerabilities. Examples of security impacts include an increase in access for an attacker, a decrease in availability of a target, or another violation of security policy.

4.2.2.1.1-3 CNAs SHOULD assign a CVE ID...
4.2.2.2.1-3 CNAs SHOULD Publicly Disclose and assign a CVE ID if the Vulnerability...

4.2.5 CNAs MUST NOT assign CVE IDs for Vulnerabilities the CNA does not intend to Publicly Disclose unless the Vulnerabilities are already or are expected to be Publicly Disclosed.
4.2.7 CNAs SHOULD assign CVE IDs to Vulnerabilities, not Fixes for Vulnerabilities. CNAs SHOULD assign CVE IDs whether or not a Fix is available.

4.4 CNA Judgment

4.5.3.6 CNAs MAY reject published CVE Records.

My apologies in advance that the followup post will be long.

Warning, long post:

The CVE process has a several steps
Reservation is the obtaining of a CVE ID by a CNA(the DST) for assignment.
Assignment is the issuing a CVE ID to a vulnerability report
Publication of a CVE Record is making the formal CVE report public (this is basically what you see on the MITRE site)
Publicly disclosing the vulnerability is providing details about the report. This would be creating an issue in the public issue queue or creating a "Drupal Security Advisory"
A Drupal Security Advisory is not the same as a CVE ID Assignment or a CVE Record. The processes should be thought as closely related, yet separate.

Section 4.2.1 discusses the DST's initial right to assign a CVE ID while 4.2.1.2 and 4.2.1.3 discuss the process for escalating the issue to a different CNA if the DST declines to invoke its rights as a CNA. These two sections should be taken into account anytime "should assign" is discussed in the CNA policy. While the DST is not required to assign when they do not they are yielding the determination and control to to another CNA. The DST would need to provide strong reasoning that the issue does not meet the definition of a Security Vulnerability. See discussions regarding section 4.1.

4.2.2.1.1-3 recommends the DST to assign a CVE ID if a vulnerability to exists (as defined by 4.1) in the Drupal Ecosystem when a disclosure is already public or expected to be made public (including the DST instructing a public issue to be made).

4.2.2.2.1-3 recommends that the DST assign and publicly disclose the issue itself if a vulnerability exists (as defined by 4.1) and either 'significant harm' is likely to be present or other parties (such as site owners or contrib modules) need to perform their own risk assessment to determine the vulnerability impact. This can include low severity issues. I will note that the Webinar discussions suggest publishing if not sure.

The webinar also mentions do not aim for No CVE's as that is unrealistic instead aim for disseminating information efficiently and allowing those who may be impacted perform their own risk assessments. One site owner may do nothing with the CVE while another may need to take immediate mitigating action while awaiting for a final resolution. These two action paths are completely acceptable, the key is that it was the site owners choice.

4.2.2.1 and 4.2.2.2 show us the DST has two different options for an issue that meet the definition of a Security Vulnerability. The first option is just assignment of a CVE ID with publication of the CVE record, while a secondary option is "actively disclosing the vulnerability" in addition to the assignment of a CVE ID and publication of a CVE record.

4.2.7 recommends that the DST assign a CVE for unfixed issues. The point of CVE's is to communicate the vulnerability not the resolution. Again keep in mind that while the DST does not need to assign a CVE ID until a fix is made, if they wait one may be issued by a different CNA and communication on the issue is hindered. It would be in the DST interest to publish themselves for direct control of the CVE Record.

Section 4.1 provides us the basis of what is a security vulnerability. A security vulnerability is officially defined as a "weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy." Any condition that meets the preceding definition is a vulnerability.

Using this issue as our reference it could initially be described as "When using a recommended method for setting the site hash salt under certain error conditions a weakness in the error logging handler may disclose the full path to where the hash salt file is stored"

I would suggest we wish to refer to CWE-209: Generation of Error Message Containing Sensitive Information as the closest CWE for this fault. CWE-209 notes that "sensitive information may be valuable information on its own (such as a password), or it may be useful for launching other, more serious attacks."

CWE-209 requires judgment of "is the path sensitive information" and "can the path be useful for launching other more serious attacks". If we reefer to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor we are advised that different parties may have different assessments regarding if the leaked information is sensitive (see 4.2.2.2 for implications of risk assessments required by third parties).

Addtionaly the hash salt is part of Drupal Cores Access Control and Authorization system (per previous Drupal Security Team decisions in consult with Drupal Core maintainers). I would contend reasonable judgment in this case is that the file path itself meets the definition for sensitive information similar to how the location of the private key for any cryptography system may be seen as sensitive.

The next most relevant checkpoint would be 4.1.2 which advises that a CVE should only be issued if a security impact exists. I emphasis this does not say "significant security impact" it just says "security impact" even low impact issues should still be issued a CVE ID.

'Impact' here is certainly hard to quantify on the initial report. Security Impact is not specifically defined however examples given are "an increase in access for an attacker, a decrease in availability of a target, or another violation of security policy". The path itself does not directly increase access (obtaining the contents of the file could, but not the path to the file). It is unlikely this would create a decrease in availability of Drupal. Is this a a "violation of security policies", that is not clear. With the examples dismissed we are left with just the plain English of "security impact' requiring a person making a judgment to ask questions of how might that path post risks. What if the path is inside the docroot or inside a path that is accessible by a streamWrapper (eg private://)? These are some of the "what if" that go into evaluating if an impact could exist.

CNA Judgment (4.4):
In many cases as noted the DST has to make a judgment call. This is affirmed by the CNA standards. The questions that would come to mind on this issue would be did the DST dismiss this without an in depth response from the Drupal Core Team, or did the Drupal Core Team provide information indicating there was no method this could be used as part of an additional exploit chain.

I would welcome a statement from the Drupal Core Team and the DST (in their official capacities) that provides a justification for each point in sections 4.1 regarding is this or is this not a vulnerability as backed up by CVE program reference material. Even if we do not agree on the decision providing the logic would at least provide a baseline to understand where we are both starting from.

In this case it appears MITRE decided this issue was a vulnerability (4.1) and that it had a security impact (4.1.2) justifying publication. MITRE is running on basic standard principals of Vulnerability evaluation.

Again from the CVE 4.0 workshop meeting, when in doubt, it can be beater to error on the side of assigning a CVE ID to allow those who use the product to run their own risk assessment.

@mcdruid asks:

How would sites decide whether they should priorities updates that were fixed in public but got an SA? Presumably the SA would only be published once the fix was committed?

I would suggest a CVE ID would be assigned and published immediately. It would be the DST option if they public more on D.O. however the more they publish the more they can inform site owners and control the narrative. his initial SA would not necessarily need to be emailed to everyone just to be available via the normal inputs (CVE registry, the Composer Security Audit Endpoint,etc)

Using this issue as an example the SA could originally had said "This issue will only impact your site if you use file_get_contents() to retrieve the salt hash, and if errors occur. This is expected to be extremely rare, until this issue is resolved sites may block access to authorize.php unless they are "

As the issue involved the SA could have been updated to indicate "install.php should also be blocked, additionally the issue is known to leak additional information such as database identities"

Final update would be "A patch may be downloaded from foo, and the bar release is available for all sites to use". The DST would likely desire for this one to be published via the general feed to inform users a final fix is available.

During the time of CVE Record Publication and Final Fix the Drupal Core team can take any amount of time it desires to resolve the issue. Assuming I applied mitigations (blocking the two access points) a proper security audit against my site will indicate that mitigations are in place (the paths are not publicly accessible) and that I am not impacted by the published CVE.