- 🇺🇸United States dww
This whole UI is being removed at 📌 Remove adding an extension via a URL Fixed . I don't think we need any followups anymore, and we should call this fixed.
Automatically closed - issue fixed for 2 weeks with no activity.
This is either a bug or a documentation issue, but it's important we figure it out.
In Drupal 7, the "rule" is that you need to have the PHP module turned on in order to be able to execute arbitrary PHP code. This was especially intended as a result of http://drupal.org/node/224333#php_permissions and related issues. The idea is that if you want to lock down your Drupal installation from arbitrary code execution, you can remove the PHP module from the filesystem, or block it from ever being enabled via custom code. That way, even if someone stumbles across a computer with an administrator logged in, there is a limit to the damage they can do.
However, the Update Manager functionality breaks this assumption. In "normal" operation of the Update Manager, this is certainly by design (as the entire purpose is to let you upload arbitrary code to your server) - however, in normal operation it also asks you for your FTP or SSH credentials right before letting you upload, so that's fine because if someone knows those they can already upload things to your server outside of Drupal.
But for certain server setups (in particular, situations where the webserver user owns the Drupal files - i.e. setups that are popular in shared hosting) the Update Manager does not ever ask you for a server password (this results from #609728: Skip authorize.php step if webroot files are owned by the httpd user → ). It just lets anyone logged-in with the 'administer software updates' permission upload modules to the site.
We need to decide if it's acceptable to allow that with the PHP module turned off. If it is, we need to document somehow that disabling access to the update manager (which can be done through settings.php) is sometimes necessary as part of any procedure to disallow direct arbitrary code execution (without knowledge of SSH/FTP passwords) on a Drupal site. Right now, I don't believe there is any indication of that.
Fixed
11.0 🔥
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
This whole UI is being removed at 📌 Remove adding an extension via a URL Fixed . I don't think we need any followups anymore, and we should call this fixed.
Automatically closed - issue fixed for 2 weeks with no activity.