Maintenance pages leak sensitive environment information.

This issue is missing needed images and does not include a message about having been a privately-reported security bug that was cleared for public view.

Note: The issue was reported privately to the Drupal security team, but it was decided that it can be solved in public.

It seems like the error output is caused by the fact, that the authorize.php is run with MAINTENANCE_MODE constant defined. That will cause that all errors are displayed unconditionally, see: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/includes/erro...

function error_displayable($error = NULL) {
  if (defined('MAINTENANCE_MODE')) {
    return TRUE;
  }
  ...
}

Therefore the warning is printed even if Drupal error reporting is turned off.

Not for D.O. community members.

It appears this issue has been assigned CVE-2024-45440.

I have submitted a request for comment to the Drupal Security Team(DST) questioning if MITRE issued this through their responsibility as CNA-LR (publishing CVE for valid security concerns when the responsible CNA declines) or if it was for other reasons. I am awaiting feedback from the DST when they have more information.

In either case I do believe this is an example to illustrate that the DST frequently chooses not to publish security advisories for issues that the wider cybersecurity industry would consider security flaws and frequently fails to guide issues to a resolution in a timely manner.

We should all be looking at the DST to increase the accountability of maintainers of core and contribution projects to allow Drupal to continue marketing itself as a "Secure" solution. If not we could risk Drupal being removed from sites at a time we are trying to increase user counts.

$ composer audit
Found 1 security vulnerability advisory affecting 1 package:
+-------------------+----------------------------------------------------------------------------------+
| Package           | drupal/core                                                                      |
| Severity          | low                                                                              |
| CVE               | CVE-2024-45440                                                                   |
| Title             | Drupal Full Path Disclosure                                                      |
| URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
| Affected versions | =11.x-dev                                                                        |
| Reported at       | 2024-08-29T12:31:05+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+

$ composer audit
Found 1 security vulnerability advisory affecting 1 package:

Core should be thankful that the GHSA announcement (currently) only flags the 11.x dev branch when it appears it could tag production releases (cursory quick test shows reproduction in 11.0.1). Given the code in question is over a decade old, it could be closer to >= 8 (untested, however GitLab indicates the commit adding the referenced line present in tag 8.0.0).

If the GHSA were to be amended this could get painful from an ecosystem standpoint.

I will note it was mentioned on Slack that roave/security-advisories now prevents installing the 11.x dev branch (likely due to this GHSA post).

It will be interesting to see where this issue goes. On a cursory review this is not a "Drupalgeddon" vulnerability, however the vast majority of CVE's are not. Yet even the lowest CVE informs those of us who deploy software of the risks we need to be aware of and the audits we need to perform.

Even if this CVE ultimately is retracted I hope we use this as a learning experience to improve our security posture.

@cmlara Not speaking directly about this issue, but there are multiple policies regarding Drupal Security Team and specific vulnerabilities - for example ones mentioned by this PSA: https://www.drupal.org/psa-2023-07-12 → , or other exceptions here: https://www.drupal.org/drupal-security-team/security-advisory-process-an... →

If you are concerned about specific policy, feel free to open an issue to discuss it. Thanks!

If you are concerned about specific policy, feel free to open an issue to discuss it. Thanks!

Others and myself have.

In some cases I would raise a concern on an issue or in SLACK (where we’re discussing a problem and a possible solution fixes said problem as well as additional problems at the same time) and been shut down so aggressively by DST members that my concern was an actual dedicated policy change issue would likely have been filed as a D.O. Code of Conduct violation.

If you, in your role as a security team member, are saying the team would like dedicated issues for these I can attempt to review my records and open outstanding concerns.

or other exceptions here

I’m not sure we have an official name for this in the industry however we recognize this as CNA’s that refuse to publish “valid” security concerns.

This is why I mention the CNA-LR portion of the program in previous posts and in direct questions to the DST. The CNA-LR is one method vulnerability reporters have to bypass a CNA that fails to publish a CVE for a “valid” threat. Either MITRE failed to defer this to the registered CNA, or they published this as a CNA of Last Resort(other CNA refused to publish or no other CNA held scope, both could apply based on how this CVE was written to target the development branch which the DST CNA explicitly lists as outside its scope).

Subnote: The CNA program has recently changed to v4 rules, I’m more familiar with v3 rules, and some of these processes may have changed in v4.

The DST has refused to adopt new standards in the past due to “labor” concerns, and yet advocates against requests to reduce their labor by giving maintainers more autonomy similar to GitHub.

Let's please keep the comments here focused on solving this problem. Commenting about other topics distracts and makes it harder to solve the problem.

Thanks, @poker10 for your analysis so far.

I read the analysis in #6 and it seems that MAINTENANCE_MODE is being "overloaded" and used to indicate 2 purposes. Unless there is a specific reason why errors really should be shown when a site is in MAINTENANCE_MODE, it seems ideal to remove this behavior OR create 2 variables, one for MAINTENANCE_MODE and another for something like MAINTENANCE_MODE_SHOW_ERRORS to have each variable behave as intended and avoid using one variable for 2 purposes.

While the overall impact (as noted in the CVE) is LOW In accordance with the Issue Priority Field documentation I'm the upgrading priority to Critical as the issue meets the condition "Expose security vulnerabilities" as documented by the issuance of a CVE by an approved CVE Numbering Agency. We addtioanly have risk the CVE could be reviewed and publish releases added to the CVE.

The priority can reduced if the CVE is retracted.

Opened 💬 Publication of CVE-2024-45440 by MITRE Active for the directly related discussions regarding the publication of the CVE by MITRE and its impact on the D.O. ecosystem.

Restoring template to assist with tracking the work here.

Could the issue summary be cleaned up not to say “traversal” because this isn’t a traversal? Since it’s a critical now it should be accurate.

It’s displaying the install path when there is a coding error causing an exception in settings.php.

It’s displaying the install path when there is a coding error causing an exception in settings.php.

DST: What other error types does this expose that should otherwise be hidden? Connection errors with hostnames or usernames (and in the case of really bad code passwords)? I'm thinking about Database or Queue modules off hand though I'm sure there are others here.

While the file path is a great example my first though based on the code linked in #6 is the issue description might currently be under-scoped. A report by the DST of what could leak would help us better title this issue.

> A report by the DST of what could leak would help us better title this issue.

That research can (and should) be done by anyone. There's no special access that makes it easier or better to be done by a member of the Security Team.

That research can (and should) be done by anyone. There's no special access that makes it easier or better to be done by a member of the Security Team.

I was expecting the DST to have easy access to this as part of a Root Cause Analysis which should have been completed prior to the issue being cleared for public disclosure which would have been in private tracker.

To answer the question I asked: Yes this flaw can be confirmed as leaking database details when connection errors occur. I would assume any other 'early bootstrap' issues could leak as well occur too.

Invalid database:
PDOException: SQLSTATE[HY000] [1044] Access denied for user 'db'@'%' to database 'db2' in Drupal\Component\DependencyInjection\PhpArrayContainer->createService() (line 77 of /var/www/html/web/core/lib/Drupal/Component/DependencyInjection/PhpArrayContainer.php).

Invalid username or password:
Drupal\Core\Database\DatabaseAccessDeniedException: SQLSTATE[HY000] [1045] Access denied for user 'db'@'172.16.5.68' (using password: YES)

Re titling issue. This needs an IS update, though care should be taken as this is the linked document for a published CVE.

Adding a related issue which propose to remove MAINTENANCE_MODE == 'update' (which is used in authorize.php as well).

authorize.php should be completely deprecated for removal when ✨ Add Alpha level Experimental Automatic Updates module Needs work is done.

In the meantime I think we should do a minimal fix to not show errors when MAINTENANCE_MODE = update is set, or to prevent setting it altogether in authorize.php (as long as that doesn't prevent it from working at all).

Thanks for that advice, catch. I do think pursuing the short-term path could be good as it may take some time and be difficult to resolve the blocker of composer operations with roave/security-advisories.

Let's try just not automatically showing errors when MAINTENANCE_MODE === 'update' and explicitly check for 'INSTALL'.

Put an MR up that adds an additional check for MAINTENANCE_MODE === 'install' in the error handler. Pipeline is green which means there's zero test coverage for error handling and MAINTENANCE_MODE === 'update' but also means this isn't breaking anything else.

@catch What about the install.php also leaking? Do we have any protection on a default install to prevent prying eyes from reaching through this vector?

I've added a list of versions I've tested against in the D8+ series. No surprise, our entire D8+ line appears to be subject to this.

This "override" code was added in #742246: Handle uncaught exceptions → in 2010, so no, this is not new and it is a part of Drupal for 14 years. The same code is also in D7 - with the difference, that there is explicitely check for updating, so this probably indicates we should be careful what the change in MR could affect:

https://git.drupalcode.org/project/drupal/-/blob/7.x/includes/errors.inc...

$updating = (defined('MAINTENANCE_MODE') && MAINTENANCE_MODE == 'update');

Drupal 8+ code was changed here to override also when installing: #2176105: Installer catches exceptions and manually re-prints them; does not use error/exception handler →

+  if (defined('MAINTENANCE_MODE')) {
+    return TRUE;
+  }
-  $updating = (defined('MAINTENANCE_MODE') && MAINTENANCE_MODE == 'update');

@poker10 in Drupal 7, update.php defined MAINTENANCE_MODE and was a separate file. update.php in Drupal 10 is a route and doesn't define MAINTENANCE_MODE at all.

In Drupal 11.x the only two places that define MAINTENANCE_MODE are install.php and authorize.php unless my grepping is failing.

So limiting this to 'install' should be absolutely fine. As above we should be getting rid of MAINTENANCE_MODE altogether anyway, but one step at a time.

@cmlara, the installer prints errors on purpose, so that people who try to install Drupal via the UI and hit environment or settings.php misconfiguration errors see an actual error messages instead of a WSOD or something else cryptic - that is the reason for the original code here. If we don't print errors in that situation, their only recourse is server logs, but there are various situations where the person installing may not have access to those (or know where they are even if they technically do).

Having said that, I think we can add a check for InstallerKernel::installationAttempted() which detects whether someone is trying to install or not. Pushing a commit for that.

the installer prints errors on purpose, so... If we want to revisit that, it needs to be its own issue again, since that will need usability input and a lot of additional testing.

It is essentially the same root fault. I would warn that while the CVE might have only said "authorize.php" the "atttack" could could easily have used install.php instead. We should expect (just by the fact we have discussed it) install.php to be included as an amendment to the existing CVE or a NEW CVE in the future.

Making it easy for the users is not always the right decision. "I intended that" does not give a pass in an audit, being able to describe the 'reasonable security controls' that are in place to reduce the risk does. An anonymous user able to pull up with no restriction is 'no reasonable security controls present', while requiring a login and validating access could be 'reasonable security controls implemented'.

InstallerKernel::installationAttempted() based on the docblock description and our limited operational capabilities at this point sounds like it could be a 'reasonable security control' though I have not done an in-depth audit to confirm.

Did some installer testing. While InstallerKernel::installationAttempted() is theoretically correct, it doesn't actually work for errors generated by settings.php

This is because unlike regular bootstrap, install_begin_request() requires settings.php before InstallerKernel::bootEnvironment() is called - so any errors from settings.php itself use the default error handler.

Two options:

1. Refactor the installer to call InstallerKernel::bootEnvironment() prior to including settings.php, this might require initializing the kernel twice - both before and after, because we use the contents of settings.php to determine what $environment should be.

2. Add a custom error handler or tweak prior to settings.php being included, or set error display to FALSE altogether until it is.

The above is exactly the reason that issues like this should be handled in the public queue - potentially significant refactors of installer handling should not be carried out in secret by a small group of people especially to fix such a marginal issue.

Can issue summary be updated to include what proposed solution is?

https://github.com/advisories/GHSA-mg8j-w93w-xjgc was recently updated - now seeing this on 10.3 latest

Found 2 security vulnerability advisories affecting 2 packages:
+-------------------+----------------------------------------------------------------------------------+
| Package           | drupal/core                                                                      |
| Severity          | low                                                                              |
| CVE               | CVE-2024-45440                                                                   |
| Title             | Drupal Full Path Disclosure                                                      |
| URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
| Affected versions | >=8.0.0,<=11.0.4                                                                 |
| Reported at       | 2024-08-29T12:31:05+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+
+-------------------+----------------------------------------------------------------------------------+
| Package           | drupal/core-recommended                                                          |
| Severity          | low                                                                              |
| CVE               | CVE-2024-45440                                                                   |
| Title             | Drupal Full Path Disclosure                                                      |
| URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
| Affected versions | >=8.0.0,<=11.0.4                                                                 |
| Reported at       | 2024-08-29T12:31:05+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+

I can confirm that #32 works.
It failed our nightly job on Drupal core 10.3.5 https://github.com/morpht/convivial/actions/runs/11003139985/job/3055159...

  +-------------------+----------------------------------------------------------------------------------+
  | Package           | drupal/core                                                                      |
  | CVE               | CVE-2024-45440                                                                   |
  | Title             | Drupal Full Path Disclosure                                                      |
  | URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
  | Affected versions | >=8.0.0,<=11.0.4                                                                 |
  | Reported at       | 2024-08-29T12:31:05+00:00                                                        |
  +-------------------+----------------------------------------------------------------------------------+
  +-------------------+----------------------------------------------------------------------------------+
  | Package           | drupal/core-recommended                                                          |
  | CVE               | CVE-2024-45440                                                                   |
  | Title             | Drupal Full Path Disclosure                                                      |
  | URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
  | Affected versions | >=8.0.0,<=11.0.4                                                                 |
  | Reported at       | 2024-08-29T12:31:05+00:00                                                        |
  +-------------------+----------------------------------------------------------------------------------+
  
  The new audit.abandoned setting (currently defaulting to "report" will default to "fail" in Composer 2.7, make sure to set it to "report" or "ignore" explicitly by then if you do not want this.
  Found 2 security vulnerability advisories affecting 2 packages:
  To skip commit checks, add -n or --no-verify flag to commit command

Would it be okay to add this cve to config.audit.ignore? When configured correctly this shouldn't happen correct? https://getcomposer.org/doc/06-config.md#ignore

composer audit fails for Drupal 10.3.5 because the CVE says nothing less than 11.0.4 is secure. Do we have to change our deploy scripts and remove this security check?

#34 I would agree with you

I've added:

"config": {
        "audit": {
            "ignore": ["GHSA-mg8j-w93w-xjgc"]
        }
}

to projects to reduce the noise after verifying the steps to be vulnerable were not applicable.

Confirmed #34 and #36 works. Thank you!

Updated IS to indicate there are additional related scenarios to make it easier on site owners to determine if this is a concern.

Re Audit Ignore:
#36 hits this well, if you evaluate your site to not have risk adding the GHSA to your composer.json can be a valid response (assuming no conflict with organization security policies).

I would recommend considering using the the longer version of the ignore feature to include the evaluated rational for ignore. This text will be included in the audit report.

Sample:

"config": {
    "audit": {
        "ignore": {
            "GHSA-mg8j-w93w-xjgc": "Apache has been configured to block access to applicable paths"
         }
    }
}

I have confirmed that #34 and #38 work. Thank you!

Although I have several security modules on the server, I’m considering upgrading from version 10.3.5 to 11.0.4, as the issue has been resolved in that release.

Ignoring GHSA-mg8j-w93w-xjgc does work for composer audit, but it doesn't solve the issue of composer update, where we get a conflict which prevents Drupal core below 11.0.4 from being accepted.

Can we focus this issue on fixing the bug and open a support request issue for process workarounds?

I believe we are waiting on a core team decision and action from #19.

I will note that if #19 is accurate it changes previous comments that this is same root cause and could possibly be considered “independently fixable” for install.php under CNA 4.2.11 allowing it to go out as its own CVE. I’m not sure that gains much as it just opens up another vulnerability report that still needs to be solved however it is an option.

There is a MR from catch at least 20 days old. There was no activity since that time. In #30 there are proposed options, how to continue. I do not think this is waiting for core maintainers.

I'm confused. Does this affect 10.x or not?

"Drupal core below 11.0.4"

Actually the github advisory says "<=11.04", so even 11.04 is vulnerable and will cause problems.

longwave → credited alexpott → .

longwave → credited xjm → .

This issue was discussed with several members of the Drupal security team at Drupalcon Barcelona and given that this issue is already public we decided to continue to fix this in public.

MR!9621 attempts to prevent full path disclosure in early bootstrap situations, such as the one described here, by extending the use of the Drupal error handler and adding additional hardening to the error output.

I don't remember why but I added this file to my "packaging exclusion list" (along with install.php, readme,...).
Can someone explain me what's the use of this file on a packaged deployed website (updates done only with composer)?

But if we're allowing acquia/drupal-recommended-settings (or blt) to auto-generate the salt file, we don't have to worry about this? According to the OP?

@o'briat authorize.php is only used for certain filesystem operations around updating modules directly on webservers where you don't otherwise have permission to do so.

@loopy1492 Yes, this vulnerability only exists if you have customised settings.php in a way that ends up displaying an error message, and even then all that happens is the full path on the server to the Drupal directory is exposed.

Thank you kindly for the response, @longwave. We feel safe using the temp solution in #36 and #38 then.

I reviewed the MR both in person with @longwave and DrupalCon Barcelona and also just now again with a couple of additional changes plus the test coverage.

The only thing I don't like that much is the substr() and I think we should open a follow-up to discuss whether we should just use basename() without trying to show the filepath at all (to avoid having to assume the current directory structure) - but that is very much follow-up material. Moving to RTBC.

Just for information:

I'm using Drupal 10.3.5 and composer is throwing a warning:

Found 2 security vulnerability advisories affecting 2 packages:
+-------------------+----------------------------------------------------------------------------------+
| Package           | drupal/core                                                                      |
| Severity          | low                                                                              |
| CVE               | CVE-2024-45440                                                                   |
| Title             | Drupal Full Path Disclosure                                                      |
| URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
| Affected versions | >=8.0.0,<=11.0.4                                                                 |
| Reported at       | 2024-08-29T12:31:05+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+
+-------------------+----------------------------------------------------------------------------------+
| Package           | drupal/core-recommended                                                          |
| Severity          | low                                                                              |
| CVE               | CVE-2024-45440                                                                   |
| Title             | Drupal Full Path Disclosure                                                      |
| URL               | https://github.com/advisories/GHSA-mg8j-w93w-xjgc                                |
| Affected versions | >=8.0.0,<=11.0.4                                                                 |
| Reported at       | 2024-08-29T12:31:05+00:00                                                        |
+-------------------+----------------------------------------------------------------------------------+

So not only 11.x is affected, Drupal 10 too.

Updating IS to make it more clear the impacted versions.

It would be helpful to have the CVE updated (it appears the Drupal CNA has permissions to this now if not the researcher may be able to request an update) to reflect the issue is known to occur in all branches since 8.0.0

The CVE being updated to include the additional paths would also likely make this issue more clear.

I could propose an update to the GHSA to not reference only 11.x in its text description however the CVE would be better to update and the GitHub team might require such an update to approve the GHSA to be updated.

catch → changed the visibility of the branch 3457781-maintance-pages-leak to hidden.

Updating issue credit.

I think the fix can be improved and work across OS. I think the current fix would not work on windows...

Implemented @alexpott's suggestion and further improved the way we find the root.

I think this is in a good state, let's get it in.

I committed this to 11.x, 11.0.x, 10.4.x and 10.3.x. I have to resolve conflicts on 11.0.x - so, fingers crossed I got it right. It was about having to have a variable in a try catch... I did https://3v4l.org/1UmGR to test.

I think we should backport this to 10.2 as well.

@catch good point. Done.

Opened 🐛 Maintenance Pages leak sensitive environment information - pt2 Active to deal with the followup issue from #18.

Adjusting title and IS to indicate this focused on the Full Path Discovery.

Addtionaly I'm seeing:

Error: Undefined constant "DRUPAL_TEST_IN_CHILD_SITE" in _drupal_error_handler_real() (line 87 of core/includes/errors.inc).

_drupal_error_handler_real() (Line: 166)
_drupal_error_handler()
file_get_contents() (Line: 16)
include() (Line: 765)
require() (Line: 150)
Drupal\Core\Site\Settings::initialize() (Line: 341)
install_begin_request() (Line: 118)
install_drupal() (Line: 53)

With 10.3.x-dev. when placing file_get_contents("/dev/invalid"); in settings.php. and visiting core/install.php

Do we want to re-open this issue or create a new child issue to resolve?

Let's open a new issue for that one, not immediately seeing how that's getting through the defined() call in the MR, at least there's no path disclosure any more.

Created 🐛 Error handler crashes with Undefined constant "DRUPAL_TEST_IN_CHILD_SITE" Active

And this time actually changing the issue title that I failed to do in #72

Can someone update the effected version ranges in https://github.com/advisories/GHSA-mg8j-w93w-xjgc with all the fixed versions below 11.04?

@heddn already done at https://github.com/github/advisory-database/pull/4865, waiting for GitHub to review it.

The pull request will have to be merged before sites can update if they require roave/security-advisories, since the latest release is still counted as vulnerable in the meantime.

Just merged: https://github.com/github/advisory-database/pull/4865

I also reproduced this on Drupal 7 and opened a child issue. I used D7 Lando instance with PHP 8.3 and "Error messages to display" is set to "None".

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