Hi,

I know this is a very frequently asked question but after spending many hours searching for an answer I decided to open a new thread.

Background
Drupal Security Announcement 2006-006 was concerned about a highly critical vulnerability of remote arbiraty code execution in some (very common) Apache configurations. If I'm not mistaken the scenario was that users with permission to upload files to the Drupal site were able to somehow upload an evil PHP script to the upload folder in some Apache configurations, then run them from the files directory and ka-boom, the site is compromised.

For this reason, Drupal SA 2006-006 introduced a .htaccess file in the files directory with the following content:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

Description of the problem
The hosting provider of my current project has Apache configured so that these lines cause problems.

I'm able to upload content to the files directory with no problems: if I upload files they end up in the files directory as expected. If I change the color of my Garland theme the color module is able to create a subdirectory in the files directory and save the new CSS-files etc. in this directory. The file permissions of the uploaded files are OK (-rw-rw-r--). So far so good.

The problems, however, start when the browser is trying to access these files.

Problem #1. The FollowSymLinks option causes me an Internal Server Error because my hosting provider has disabled use of this directive. In my environment I know I can safely comment this line out just like I did in the main .htaccess file in the Drupal installation directory. This is because the FollowSymLinksIfOwnerMatch is enabled instead. One down, one to go.

Problem #2. The content of the .htaccess file is now effectively as follows:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None

With this configuration I get rid of the Internal Server error. But instead, I now get a HTTP 403 forbidden error when the browser is requesting files that are in the files directory.

If I comment out Options None, I can access the files as intended. This configuration change is, however, something that I am not going to do unless I know for sure that Apache is configured safely - I don't want to open my site for remote arbitrary code execution.

My request for support
Could someone please point me to a piece of documentation where I could read how to make sure that the Apache environment is configured safely so that the Options None could be safely removed.

Comments

cog.rusty’s picture

I think your question is equivalent to:

"Are there any apache Options settings which, if not disabled, can allow a PHP script to run, in spite of garbling the handler?"

The logical answer seems to be "no". But do upload a php script and try to run it and see what happens.

masipila’s picture

I think your question is equivalent to:

"Are there any apache Options settings which, if not disabled, can allow a PHP script to run, in spite of garbling the handler?"

The logical answer seems to be "no". But do upload a php script and try to run it and see what happens.

Yes, I guess you could phrase my question to that.

Here are the test that I made:

Test 1

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

Result: I get an internal server error when trying to load any file in the files directory because the FollowSymLinks is disabled as I mentioned in the first post.

Test 2

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
#Options +FollowSymLinks

Result: I get a "HTTP 403 forbidden" error when trying to load any file in the files directory.

Test 3

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
#Options +FollowSymLinks

Result:
- Normal files work normally
- I created a test.php which was not executed by Apache, Apache treated it as any file and the browser started a download as it would do to for example a PDF-file.
- To me it looks like this configuration is enough to prevent arbitrary code execution.

Test 4

#SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
#Options None
#Options +FollowSymLinks

Result: As expected, Apache executed the test.php, which is bad.

Summary

  • The tests that I made suggest that in the normal case it is not possible to execute arbitrary PHP from the files directory when using the configuration in test 3.
  • The question reduces to "Are there any Apache Options settings which, if not disabled, can allow a PHP script to run, in spite of garbling the handler?" just like cog.rusty pointed
  • My tests don't give a explicit answer to this question and I do not know Apache deep enough to answer the question.
  • I would appreciate if somebody could confirm me if my tests are enough to be on the safe side.

-Markus

cog.rusty’s picture

In your case, it has been established that you are safe at least from php scripts.
For reference, here are all possible Options:

http://httpd.apache.org/docs/2.2/mod/core.html#options

Looking at them, it seems that the only ones which hypothetically might have some relevance are:

Options -Includes -ExecCGI
masipila’s picture

Thanks again! I really appreciate your help.

jeffreyrea’s picture

This really helped me alot.