SA-CORE-2013-003 and Nginx

Posted by superfedya on November 24, 2013 at 6:48am

SA-CORE-2013-003 - Drupal core - Multiple vulnerabilities add some changes in .htaccess that not used by Nginx.

https://drupal.org/SA-CORE-2013-003

And I got the admin warning notification:
Files directory Not fully protected
Temporary files directory Not fully protected

How to remove those messages? Do I need to add something in Nginx config?

Thanks

Comments

Which config are you using?

Posted by perusio on November 24, 2013 at 6:56am

I haven't checked the patch in core, but if they look for an .htaccess it won't work.

You have to add # Set the

Posted by migmedia on November 24, 2013 at 3:14pm

You have to add

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

to the listet .htacceass. It doesn't change a bit for nginx but drupal is justified.

In your nginx.conf you have to secure this directories to does NOT execute php-files.

So far as I understand this item.

migmedia

If you have something like

Posted by migmedia on November 25, 2013 at 7:50am

If you have something like this:
1. A location just for index.php and
2. an extra location for *.php after that,
any execution of php-Files anywhere except index.php is forbidden. That's the meaning of the .htaccess-file as far as I understand.

    location ^~ /index.php {
            include fastcgi.conf;
            fastcgi_pass    127.0.0.1:9000;
    }

    ## Any other attempt to access PHP files returns a 404.
    location ~ \.php$ {
            return 404;
    }

Why are you using a

Posted by perusio on November 25, 2013 at 10:48am

match first location for index.php. Using an exact match is faster. Furthermore the point of using ^~ is to avoid matching a regex later if only and only if there's no exact matching possible.

See: http://nginx.org/en/docs/http/ngx_http_core_module.html#location

You should use:

location = /index.php {
...
} 

Thanks

Posted by hooface on November 26, 2013 at 5:21am

Thanks

Drupal 中文开发教程

The code is in lines 261-292

Posted by Garrett Albright on November 25, 2013 at 4:27pm

The code is in lines 261-292 of modules/system/system.install, in a hook_requirements() implementation. It is looking for an .htaccess in public://, private:// (if applicable), and temporary://, and specifically for the "Drupal_Security_Do_Not_Remove_See_SA_2013_003" line inside of them, but before it does that it tries to create the .htaccess files via file_ensure_htaccess(), so it seems to me that if you're seeing this error, it means Drupal can't write to a directory(ies) it needs to, and therefore you have other problems.

Of course, Nginx (or Lighty or IIS or so on) can't do anything with the .htaccess files, but I don't think there's any harm in letting Drupal go ahead and create them. Just remember to lock down your site in other ways, preferably by just using perusio's config, which is sometimes annoyingly secure by default.

Perhaps a more robust test for this security problem would be for Drupal to create a PHP file in those directories and try to execute it via drupal_http_request().

The Boise Drupal Guy!

For now, hack the core, a bit

Posted by omega8cc on November 25, 2013 at 11:40pm

Like this: https://drupal.org/comment/8213137#comment-8213137

You can find related patches

Posted by omega8cc on November 26, 2013 at 10:37am

You can find related patches for D7 and D6 in this issue: https://drupal.org/comment/8213633#comment-8213633

Okay, looking into things

Posted by Garrett Albright on November 26, 2013 at 6:26pm

Okay, looking into things (and after finally getting around to update the dev version of my site myself…), I was seeing these errors after upgrading even though the directories were perfectly writable. It turns out that if there's already an .htaccess file in those directories, Drupal doesn't seem to rewrite the directories with the new versions required to make that error go away. That seems like a pretty dumb oversight (or at least one made in a hurry) and not Nginx-specific.

Probably the easiest way to fix it is to just manually delete the .htaccess files, then reload the status report page. Drupal will recreate the .htaccess files with the necessary lines right before it checks if they exist again.

The Boise Drupal Guy!

That's still a bug

Posted by Brian Altenhofel (not verified) on November 26, 2013 at 6:35pm

It makes people in my position field more support calls than usual.

If Drupal is going to officially support Nginx, patches shouldn't go into core that cause issues for users of Nginx, especially false positives related to security. It's bad PR.

Agreed, but as I said, this

Posted by Garrett Albright on November 26, 2013 at 6:45pm

Agreed, but as I said, this weirdness isn't unique to Nginx users.

The Boise Drupal Guy!

Well it's sad

Posted by perusio on December 8, 2013 at 3:21pm

that Drupal continues to be bound to legacy tech like Apache. The patch in core is Apache centric. What it needs to be done for all users is to have a module/function that traverses all Drupal aware directories creates a oneliner PHP script and issue an HTTP request to see if gets a 200 status reply.

Relying on checking for .htaccess is going deeper into Apache only land, which besides being sad goes agianst the Zeitgeist.

Patches welcome.

Posted by greggles on December 9, 2013 at 1:13pm

Patches welcome.

knaddison blog | Morris Animal Foundation

Hmm

Posted by perusio on December 10, 2013 at 9:08am

there are really two things AFAICT:

Patch core so that it does the testing.
Define a configuration option for keeping false positives to a minimum.
In D8 this would be a configuration option for modules, in D7 some sort of configuration
option using a hook so that it states please whitelist this module.

I'm thinking of the ad module for example, that uses a custom PHP script, or the spell
checker for some WYSIYG.

This needs some further thinking and above all some code. Let's see if I can squeeze a few hours this next Friday.

Probably the first thing to do is to open issues for D7 and D8. Should this be backported to D6?

I'll be at Szeged at devdays

Posted by perusio on February 21, 2014 at 8:34pm

the plan is to work on the getting the best possible configuration for running Drupal 8 in nginx.

There's an all new bunch of things to pay attention to. So the idea is to start from Drupal 8 and backport to D7, if not totally at least partially.

For D7 probably the best option is doing through a contrib module.

I'll be there too and happy

Posted by rodrigoaguilera on February 24, 2014 at 11:58am

I'll be there too and happy to work on this.
Are you going to propose a sprint?

Please help improve my

Posted by omega8cc on December 9, 2013 at 12:47pm

Please help improve my patches to get it (kinda) fixed in Drupal core finally: https://drupal.org/node/1559116

I respectfully disagree with

Posted by Garrett Albright on December 9, 2013 at 9:56pm

I respectfully disagree with an aspect of your patch.

The Boise Drupal Guy!

.htaccess are bads for my company

Posted by erin33600 on January 30, 2015 at 10:12am

hi,

I work in a company in which drupal website we do are located on highly restrictive servers... This is done on purpose for security reason but everything which is not a mod_rewrite atomatically lead ton 500 error, so we have no choice then empty htaccess of drupal which mean error on report page...

what I mean is htaccess are the worst way of patching error in core because it is not compliant with restrictive infrastructure like ours (and I don't think we are alone in that case...)

use httpd.conf

Posted by mikeytown2 on January 31, 2015 at 12:20am

http://drupal.stackexchange.com/questions/108301/adding-htaccess-within-...

SA-CORE-2013-003 and Nginx

Comments

Which config are you using?

You have to add # Set the

If you have something like

Why are you using a

Thanks

The code is in lines 261-292

For now, hack the core, a bit

You can find related patches

Okay, looking into things

That's still a bug

Agreed, but as I said, this

Well it's sad

Patches welcome.

Hmm

I'll be at Szeged at devdays

I'll be there too and happy

Please help improve my

I respectfully disagree with

.htaccess are bads for my company

use httpd.conf

Nginx

Group organizers

New groups

Group notifications