Problem/Motivation
The commit from #140 of #1269780: Remove symlinks option from .htaccess made changes to the vendor/.htaccess and auto-generated .htaccess files (such as the one in sites/default/files). Drupal 8.0.0 is now explicitly setting Options -MultiViews in these .htaccess files, which is not allowed in some configurations without "AllowOverride MultiViews" in the VirtualHost. The commonly set "AllowOverride All" does not actually include MultiViews, which can cause further confusion.
Affected Apache configurations will be able to install Drupal but will return 500 Server Errors for any content inside the files directory, which includes CSS aggregation files and theme files such as the site logo.
However the problem is that multiviews is a possible security issue - see https://hackerone.com/reports/25382
Proposed resolution
- Remove Options -MultiViews from the offending .htaccess files, since neither directory it appears in uses Clean URLs or RewriteRules.
- Enable
Options -MultiViews
in the root .htaccess with a large comment about pitfalls - Comment on some systems needing to set a
Options +FollowSymLinks
orOptions + SymLinksIfOwnerMatch
Remaining tasks
Confirm rationale in #5
Test patch in #5
Document fix for users who have already installed.
User interface changes
None
API changes
None
Data model changes
None
Original report by @w1nz0r
hi,
i've made a fresh install with php 5.6.13 and after successful installation there is no theme used for any sites. Even setting the seven theme as default or changing back to the bartik theme doesn't work. All i see is a unformatted list of all titles and links on white background.
Any ideas how to fix this?
regards
w1nz0r
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedw1Nz0r created an issue. See original summary.
Comment #2
morenstratSame here on a fresh install. Does not happen with upgraded versions. I have to turn off css aggregation and then bartik and seven look nice.
The requests for the aggregated css files create a 500 Internal Server error:
Apache Error Log:
The .htaccess in the public files directory generated by earlier D8 versions was different. It contained
instead of
Comment #3
catchThis looks like we ran into it once before:
#919596: -MultiViews in .htaccess requires odd AllowOverride Options=All,MultiViews.
If you're experiencing the error please indicate Apache version/platform,
Comment #4
catchAlso the issue title indicates the workaround if you're affected, https://mathiasbynens.be/notes/apache-allowoverride-all has more detail too.
Comment #5
damien_vancouver CreditAttribution: damien_vancouver as a volunteer commentedI think there's an easy solution here. Can anyone think of a negative implication from NOT defining Options -MultiViews in the files directory?
MultiViews can cause problems with clean URLs (or so says the Clean URL documentation guide), and that is why we avoid them.
But files directory and vendor directory files are never accessed via Clean URLs. They get called with a direct URL, and there are no RewriteRules in the .htaccess files in either of those directories for MultiViews to fight with.
So, since that directive isn't doing anything for us, an easy fix would be to just remove the -MultiViews from the generated .htaccess files and the vendor .htaccess file. Patch attached.
Comment #6
catchTook a while but found the php docs for this:
http://httpd.apache.org/docs/current/content-negotiation.html#multiviews
So it's documented that All doesn't cover multiviews.
@Damien_Vancouver what about image derivatives? That needs to be a route with the same path as the files directory.
Comment #7
damien_vancouver CreditAttribution: damien_vancouver as a volunteer commentedHi @catch,
I did some image derivative testing and it doesn't seem that leaving MultiViews enabled causes any serious problems... other than the fact it allows insecure viewing of already existing derivative images via a crafted MultiViews URL.
Here was what I tested:
- applied patch from #5 and did a clean install of latest 8.0.x
- Ensured that Options +MultiViews is set in the VirtualHost and tested it in a test directory to confirm it was working.
- created an article with a large image (image.jpg).
- Accessed the image file directly via the MultiViews Map URL (ie. went directly to its URL path at sites/default/files/2015-11/image, omitting the file extension). Apache shows the image, as is expected to happen with mod_negotiation enabled and Options +MultiViews set.
- Viewed the article in Drupal, which shows a thumbnail of the image using the "medium" style. Clicked to view the article in full mode. Both the "medium" and "large" styles worked as expected.
- Took one of the derivative URLs and removed everything after the file extension (ie. the .jpg?itok=XXXXXXX). The image derivative displayed as one would expect with MultiViews on. (This is a security side effect of MultiViews)
- Deleted the image derivative files from both style directories and verified that they are regenerated and load correctly when going to their direct URLs or refreshing the page in Drupal. (mod_rewrite rules from the top level .htaccess firing for a nonexistant file or directory and running as expected).
- Removed the image derivative files again and tested that the files would not load with the full URL and the token missing (sites/default/files/styles/large/public/2015-11/image.jpg). I received access denied as expected.
- With the derivative file still removed, I tried accessing its filename using a constructed MultiViews URL (the filename with no extension or token). I also received an Access Denied on this request..
These last two tests show that the DoS protection for secure image derivatives is still functioning with MultiViews on. While an anonymous attacker can get around needing a token to view an image derivative file that already exists, (s)he cannot force image derivative generation for arbitrary files, which was the DoS vulnerability that secure image derivatives fixed.
So, as far as I can tell, the only problem with not having Options -MultiViews, is: if someone has MultiViews turned on, then they are effectively allowing an attacker who constructs MultiViews-style URLs to view already-generated image derivatives, despite not having the correct token.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedBecause of problems with the contextual module i also had to disable javascript aggregation as you can read here and here.
Comment #9
catch@Damien_vancouver I'd expect to be able to view already generated files without the token already, so not sure even that is an issue?
Comment #10
damien_vancouver CreditAttribution: damien_vancouver as a volunteer commented@catch,
You're right, I must have been trying to load it without the file present when I got the Access Denied. Already existing images are returned without a token.
Comment #11
catchTagging 8.0.1 target, it's not clear how many people are actually affected by this, or whether it's less or more than were affected by the original bug that was fixed, but would be good to get it fixed in the next patch release so we don't need to find out either way.
I think just removing this option is probably OK, my assumption is that the original -MultiViews when added to core was probably a copy/paste rather than in response to a specific vulnerability. However I'll try to find the history of the original issue that added it, and also we should add a note to drupal.org/requirements recommending that it's set in vhosts configuration, as well as a change record update to https://www.drupal.org/node/2608772 saying the same.
Comment #12
catchComment #13
damien_vancouver CreditAttribution: damien_vancouver as a volunteer commentedI added mention of setting Options -MultiViews if it's enabled by default to https://www.drupal.org/requirements/webserver , and updated the change record at https://www.drupal.org/node/2608772.
There was a typo in the issue description so I've updated that as well.
Comment #14
desro CreditAttribution: desro as a volunteer commentedHello.
I just installed 8.0.1 on my host server and I am having an issue in which css and js files are not loading and I'm getting a error code 500. It affects the toolbar and doesn't load enough css for me to properly access all of the administrative options when I'm logged in as the first user.
I don't have access to the Apache config files, so I was wondering if there was another way to fix the issue than the method prescribed by earlier comments or if a patch was in the works. The host I'm using is running PHP 5.6.16
Comment #15
cilefen CreditAttribution: cilefen commented#2620220: CSS/JS aggregates do not load: HTTP 500 errors when mod_lsapi is installed
Comment #16
cilefen CreditAttribution: cilefen commentedComment #17
hswong3i CreditAttribution: hswong3i commentedPatch update with latest 8.1.x-dev
Comment #19
mayurjadhav CreditAttribution: mayurjadhav commentedPatch with latest 8.1.x-dev drupal version.
Comment #21
mayurjadhav CreditAttribution: mayurjadhav commentedComment #22
mayurjadhav CreditAttribution: mayurjadhav commentedAgreed, why patch failed testing. Uploading patch with excluding vendor directory changes.
Comment #24
hswong3i CreditAttribution: hswong3i commentedPatch updated for drupal-8.2.x-dev
Comment #26
alexpottI think this issue needs an expanded scope. The problem we have is that it appears impossible to generate an .htaccess that offers the maximum security for everyone. The change that caused this issue to be created was #1269780: Remove symlinks option from .htaccess which we did because hosters where moving to the more secure module of only allowing symlink to be followed if the owners matched. If the webserver is configured to allow mutliviews we certainly don't want our files directory to behave the way that multiviews works. However it is a totally reasonable webserver configuration to not allow multiviews to be overridden. Also it appears that #1269780: Remove symlinks option from .htaccess broke OpenSuse.
So what's the best way forward? I think:
AllowOverride All
but as pointed out that doesn't include multiviews - so we need to remove this from the auto-generated htaccess files.I'm not convinced this is a major because there is a workaround by updating your apache config, we are doing the secure thing for most people, and we haven't had reports of this affecting any major hosters. But that doesn't mean we shouldn't try to make life easier for more custom webserver configurations.
Comment #27
damien_vancouver CreditAttribution: damien_vancouver as a volunteer commentedRegarding the OpenSUSE breakage,
@alexpott wrote
As a result of the reports in #1269780: Remove symlinks option from .htaccess , I filed a bug with SuSE explaining the problem with their configuration. The problem is not Drupal specific and can occur with any use of mod_rewrite if one don't explicitly set a Symlink option. https://bugzilla.suse.com/show_bug.cgi?id=955701 and as a result they modified their apache configuration file to have some hints on how to properly enable mod_rewrite: https://build.opensuse.org/request/show/347918 ("apache2-default-server.conf" changes).
That change should now be pushed to anyone running the stable Leap should have it from last November's 42.2 release. However, it's just two lines of text that could easily be overlooked - it has no mention of "Clean URLs":
Extra documentation in Drupal's .htaccess will definitely be helpful.
Here is a first draft of something short:
For the documentation page, Here is a draft of some new text to replace the existing "Symlinks" paragraph at https://www.drupal.org/docs/7/system-requirements/web-server.
If that looks OK I can add it as a documentation edit. Anything missing? Too wordy?
The MultiViews stuff proposed in #26 seems sensible and safe as well.
Comment #28
alexpott@damien_vancouver thanks for the information - that looks really good. I've updated the issue title and issue summary.
Comment #32
andypostComment #35
hswong3i CreditAttribution: hswong3i commentedre-roll for 8.8.x and 8.9.x
Comment #39
ao2 CreditAttribution: ao2 as a volunteer commentedIt looks like the reroll for 8.9.x in #35 is exactly the same as the one for 8.8.x and for me it didn't work, uploading a working version.