silverstripe / silverstripe-framework

Silverstripe Framework, the MVC framework that powers Silverstripe CMS
https://www.silverstripe.org
BSD 3-Clause "New" or "Revised" License
721 stars 821 forks source link

SilverStripe requires extra configuration to work with Apache 2.4.X's "Require" directive #9001

Closed Zaita closed 5 years ago

Zaita commented 5 years ago

Affected Version

Apache 2.4.39+

bigfork/silverstripe-oauth-login 2.0.0 SilverStripe logins via OAuth2, using the PHP League's OAuth2 client dnadesign/silverstripe-populate 2.0.0 Populate your database through YAML files friendsofphp/php-cs-fixer v2.15.0 A tool to automatically fix PHP code style lekoala/silverstripe-debugbar 2.0.3 DebugBar for SilverStripe CMS phpro/grumphp v0.14.3 A composer plugin that enables source code quality checks. phpunit/phpunit 5.7.27 The PHP Unit Testing framework. ramsey/uuid 3.8.0 Formerly rhumsaa/uuid. A PHP 5.4+ library for generating RFC 4122 version 1, 3, 4, and 5 universally unique identifiers (UUID). sensiolabs/security-checker v5.0.3 A security checker for your composer.lock silverstripe/graphql-devtools dev-master d73f56c Tools to help developers building new applications on SilverStripeâs GraphQL API silverstripe/postgresql 2.2.0 SilverStripe now has tentative support for PostgreSQL ('Postgres') silverstripe/recipe-cms 4.3.0 SilverStripe recipe for fully featured page and asset content editing silverstripe/recipe-plugin 1.3.0 Helper plugin to install SilverStripe recipes squizlabs/php_codesniffer 3.4.2 PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and detects violations of a defined set of coding standards. symbiote/silverstripe-gridfieldextensions 3.2.1 A collection of useful grid field components symbiote/silverstripe-queuedjobs 4.4.0 A framework for defining and running background jobs in a queued manner thenetworg/oauth2-azure v1.4.2 Azure Active Directory OAuth 2.0 Client Provider for The PHP League OAuth2-Client unclecheese/display-logic 2.0.2 Allows assignment of conditions for display and hide of specific form fields based on client side behavior.

Description

SilverStripe is still using Order, Deny, Allow directives in .htaccess files. This was deprecated with the release of Apache 2.4 and has finally been removed as of 2.4.39 causing SilverStripe to no longer work.

https://httpd.apache.org/docs/2.4/howto/access.html https://httpd.apache.org/docs/2.4/upgrading.html

Steps to Reproduce

Run SilverStripe with Apache 2.4.39 or later. I'm using OpenSUSE Tumbleweed

Osiris:~ # cat /etc/os-release NAME="openSUSE Tumbleweed"

VERSION="20190512"

ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20190512" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20190512" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" LOGO="distributor-logo"

Error in Apache Log: /SDLT/public/resources/.htaccess: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server

Pull requests

derkgort commented 5 years ago

That could be an issue, but please read the upgrading document. At the end:

Invalid command 'Require', perhaps misspelled or defined by a module not included in the server configuration, or Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration - load module mod_access_compat, or update configuration to 2.4 authorization directives.

So you need to load the access_compat module. ( just checked, its still there in the apache2 2.4.39-2.1 rpm on opensuse tumbleweed )

But i do agree that it's good to update the default .htaccess and documentation and start using the new directives.

Zaita commented 5 years ago

Hi Dirk, Thanks for this. I'm working around it with some docker containers, but good to know its still in Tumbleweed.

S.

robbieaverill commented 5 years ago

Do you think we should update the Apache config file or the documentation? Would one of you be keen to make a pull request?

Zaita commented 5 years ago

My preference would be the .htaccess files, as this issue is going to be more common going forward as deployments of apache don't by default enable the compat mode. This is how I discovered it, I did an update in the weekend and tried to deploy SS today.

I unfortunately do not have the knowledge of SS to make a pull request at this point.

derkgort commented 5 years ago

I'm not sure where that .htaccess comes from. If you have a location, maybe in the cms, that would be helpfull. I could check it and try to make a suggestion on the changes needed. You would probably need a backward-compatible check in there too.

robbieaverill commented 5 years ago

Are we talking about the assets htaccess file? If so it’s generated from a .ss template which you could find by searching for the comment in the output file, it’s ProtectedAdapter.ss or something- sorry I’m not at a computer right now

derkgort commented 5 years ago

I found the .htaccess in these repo/files

framework/src/Dev/Install/Installer.php silverstripe/recipe-core/public/.htaccess

That's something else than @robbieaverill suggested. Am I missing something?

kinglozzer commented 5 years ago

@derkgort I believe Robbie is referring to this pair of templates which are used to generate .htaccess files in the assets directory:

They don’t seem to use Order, so should be okay.

derkgort commented 5 years ago

But the first does use "Deny from all". Which comes from the same depricated module/functions. Good to know.

Zaita commented 5 years ago

FWIW, I enabled mod_access_compat on my installation and it would not allow me to access any of the SS installation files. It seems to have some weird behaviour.

All in all, I have to modify /public/.htaccess /public/assets/.htaccess /public/resources/,htaccess

in order to get it to function.

derkgort commented 5 years ago

What did you change? And what kind of "weird" behaviour?

Zaita commented 5 years ago

In /etc/sysconfig/apache2 I enabled access_compat Note: /etc/apache2/loadmodule.conf is not used

Then I'd get 403 Access denied across the board. When I changed the .htaccess files to Require all denied to replace the Order/Allow/Deny directives everything works. This is still a bit of a hassle as when the .htaccess files are generated it stops things working (installation etc) until you correct the file manually.

My DocumentRoot is /SDLT/public/

maxime-rainville commented 5 years ago

Just had a read through all the wonderful comments. Here's what I took away. Let me know if I missed anything important.

Summary

Possible next steps

chillu commented 5 years ago

Our doc says we support Apache 2.0+ with mod_rewrite and "AllowOverride All" set

I've since rewritten the server requirements, and it no longer spells out which Apache version we support. Because specific statements like that get us into trouble, and don't age well. In the end, we provide some starting points for configuring your hosting environment, but it is not the primary responsibility of a PHP web framework to ensure compatibility with webservers.

Apache 2.2 calling it a "final release" is just another way of saying end of life, meaning they no longer provide security fixes. So this isn't really a discussion. We have a bug in our framework (current version of Apache breaks), and we should fix it to be compatible with the minimum supported version of Apache (2.4).

chillu commented 5 years ago

Some internal risk assessments on this in https://silverstripe.freshdesk.com/a/tickets/57550.

Here's the section relevant to where we apply those protections in CWP and core modules:

  1. Deny access to .ss and .yaml (potentially sensitive config values) everywhere

  2. Deny access to *.php in app/ folder

  3. Deny access to *.php in CWP 1.x (3.x) core modules

Note: All supported modules in CWP 2.x (4.x) have shifted to composer-managed directories in vendor/, which prevents access via a highlevel .htaccess file rather than module specific .htaccess files. This new style of writing modules is still opt-in, so there might be modules out there which are still affected (just not ours).

Not affected:

NightJar commented 5 years ago

Of all modules installed as part of cwp-recipe-kitchen-sink, there are the following .htaccess files:

$ find . -name '.htaccess'
./public/resources/.htaccess
./public/.htaccess
./app/.htaccess
./.htaccess
./vendor/cwp/cwp-installer/public/assets/.htaccess
./vendor/cwp/cwp-installer/app/.htaccess
./vendor/cwp/cwp-installer/.htaccess
./vendor/silverstripe/recipe-core/public/.htaccess
./vendor/silverstripe/recipe-core/app/.htaccess
./vendor/silverstripe/recipe-core/.htaccess
./vendor/silverstripe/recipe-cms/.htaccess
./vendor/silverstripe/vendor-plugin/resources/.htaccess
./vendor/silverstripe/campaign-admin/client/.htaccess

Missing from this list because it's a SilverStripe template that generates a .htaccess file: ./vendor/silverstripe/assets/templates/SilverStripe/Assets/Flysystem/ProtectedAssetAdapter_HTAccess.ss

Not going to patch SS3 modules, they're out of support save for security issues.

For the Common Web Platform (where SS3 is still in a sort of support), SilverStripe Ltd is the vendor and controls that infrastructure. Unless a security issue arises because of the compatibility module I think the value return is overly minimal.

chillu commented 5 years ago

Not going to patch SS3 modules, they're out of support save for security issues.

Yep, fair call. This is only a security issue if a server is misconfigured (not running the Apache compat module which is required for what's now effectively a legacy SilverStripe release)

NightJar commented 5 years ago

All PR's open, CI green. 💚 Calling this done.

Just waiting for mergers before closing #9001 💜

image

maxime-rainville commented 5 years ago

FYI I tried disabling mod_authz_host on my Ubuntu install just to see what kind of error you would get. I got some pretty nasty warning and Apache wouldn't even restart afterwards. So I think it's a pretty safe assumption that no one out there is running Apache 2.4 without support for Require.

WARNING: The following essential module will be disabled.
This might result in unexpected behavior and should NOT be done
unless you know exactly what you are doing!
 authz_host

To continue type in the phrase 'Yes, do as I say!' or retry by passing '-f':
maxime-rainville commented 5 years ago

Peer reviewed the 2 other PRs.

I'm thinking we probably need to get everythign merge and do a test run on SSP and CWP.

maxime-rainville commented 5 years ago

Tested on SSP and CWP. Everything works fine.

maxime-rainville commented 5 years ago

This issue has been worked on as part of a larger initiative focused on reducing the experience debt of the SilverStripe CMS.

Thank you for taking the time to raise this issue and/ or provide feedback supporting the implementation.

This is an initiative from the teams maintaining the commercially supported module list. If you're interested to read more about this initiative and keep up with our progress have a look at our blog post on experience debt.