Context: Drupal 8.2.5 and a brand new install, minimal work done on the site, entirely through Drupal: added Mayo as a theme, made it default, changed colors, added a taxonomy vocabulary with three terms, and added the Admin Toolbar and Extra Tools and enabled the Forum. I did not directly touch any of the directories or files with my SFTP client.

Several hours after this, I was notified by the ISP that there were insecure (777) directories and files: sites/default/files/php and below. Nowhere else. They had already changed them all to 755 when they notified me.

Concerned that either I had been hacked or there was a problem in my distribution, I trashed the entire thing, created a new username and password, and re-installed and reconfigured it. Within a few hours I got the same notification from the ISP about the same 777 permissions.

I have three other sites on the server, two with Drupal 7.5 and one (sadly) with Zikula. These have not been touched or a problem.

Other than doing a test install of a new 8.2.5 distribution, checking the permissions after install, and then adding a theme, checking permissions, adding a taxonomy, checking permissions (wash, rinse, repeat) I don't know where to look. Would the security review module (dev for 8.x) be useful?

Would love suggestions for where to look.

Thanks.

Comments

VM’s picture

'sites/default/files/php'

The php folder isn't a default Drupal folder. What is inside it?

Redacted as incorrect information.
There should be a .htaccess file also @ files/.htaccess is it there?

You indicate you are using a distribution. I assume you mean an install profile? If yes, which one?

Drupal 7.5 is 48 releases behind the most stable release. If you are actually using 7.5 (and that isn't a typo), then it's possible that those installs are the security hole and after gaining access someone is tucking folders into your D8 install.

sprite’s picture

The phenomenon he is describing is related to Drupal 8.x.
His observations are about a Drupal 8.2.5 installation.

The:

sites/all/default/files/php/twig

directory is part of Drupal 8.x.

It contains TWIG related files. The directory contains numereous twig related .html files and a .htaccess file with the following contents:

# Deny all requests from Apache 2.4+.
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>

# Deny all requests from Apache 2.0-2.2.
<IfModule !mod_authz_core.c>
  Deny from all
</IfModule>
# Turn off all options we don't need.
Options -Indexes -ExecCGI -Includes -MultiViews

# 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>

I don't yet know enough about the internals of Drupal 8.x or twig to provide useful insights.

spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

pheski’s picture

sites/default is present when I unpack the 8.2.5 zip. I assume that the files/php gets created either during the install process or when adding/installing a module (admin toolbar?) or a theme (Mayo). In it:

  • .htaccess
  • color
  • config
  • css
  • js
  • mayo
  • php which has a subdirectory twig
  • styles

Looking at this, the fact that it seems to be related to the Mayo theme, and the fact that it isn't there when I just unpack the zip - I wonder if installing the Mayo theme is what creates it and creates insecure permissions. I will test that tomorrow and report back.

Yes, there is a .htaccess file there.

Distribution - my sloppy language. No, I installed 8.2.5 core. (My previous two Drupal sites are the most recent 7.5.3 available. I don't see them as the problem for three reasons:

  1. No evidence of any permissions issues with them
  2. They are current in the 7.5 series.
  3. When I installed the Drupal 8.2.5 files, I did it on a different server with a different username and password.
sprite’s picture

The directory and its contents appear related to the twig theme/template engine.

http://twig.sensiolabs.org/

The twig theme engine is the built-in theme engine for Drupal 8.x.

The directory contains multiple sub-directories, each of which appears to contain a twig related .php file.

spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

sprite’s picture

The correct current Drupal 7.x version number is 7.53, not 7.5.3.

spritefully yours
Technical assistance provided to the Drupal community on my own time ...
Thank yous appreciated ...

pheski’s picture

Noted. Mistyping and lack of caffeine.

VM’s picture

Installed 8.2.5 and the folders and the files mentioned are indeed generated due to the twig engine. The question I'd have for the host is why they are being deemed an issue at 777 considering the .htaccess files are included and the file names seem to be randomized.

Even with 777 perms drupal returns a page not found when trying to access any of the files directly in my test install. This is possibly due to

# Deny all requests from Apache 2.4+.
<IfModule mod_authz_core.c>
  Require all denied
</IfModule>

# Deny all requests from Apache 2.0-2.2.
<IfModule !mod_authz_core.c>
  Deny from all
</IfModule>

in the .htaccess files within every folder in the file tree.

pheski’s picture

Thanks. I will provide this info to my host.

mmjvb’s picture

These Twig related files are the cache of compiled Twig templates produced when twig.config:cache:true.
It is the D8 implementation of Twig. Default D8 has cache:true, only advised to set it to false when debugging the templates.

See vendor/twig/twig/lib/Twig/Cache/Filesystem.php function write starting at line 25 for creating the folder and file. It uses 0777 and 0666, hard coded! Note that umask is respected for the file.

public function write($key, $content)
    {
        $dir = dirname($key);
        if (!is_dir($dir)) {
            if (false === @mkdir($dir, 0777, true) && !is_dir($dir)) {
                throw new RuntimeException(sprintf('Unable to create the cache directory (%s).', $dir));
            }
        } elseif (!is_writable($dir)) {
            throw new RuntimeException(sprintf('Unable to write in the cache directory (%s).', $dir));
        }

        $tmpFile = tempnam($dir, basename($key));
        if (false !== @file_put_contents($tmpFile, $content) && @rename($tmpFile, $key)) {
            @chmod($key, 0666 & ~umask());

            if (self::FORCE_BYTECODE_INVALIDATION == ($this->options & self::FORCE_BYTECODE_INVALIDATION)) {
                // Compile cached file into bytecode cache
                if (function_exists('opcache_invalidate')) {
                    opcache_invalidate($key, true);
                } elseif (function_exists('apc_compile_file')) {
                    apc_compile_file($key);
                }
            }

            return;
        }
pheski’s picture

Thank you. I will provide this information to my host (DreamHost), but based on my interaction with them to date, I believe they have an automated security screen that finds and changes 777s.

If the perms of 777 are hard coded, I assume that this is important to proper function? At the moment, the site appears to be working, even without 777 permissions, though I have had a couple times when I got a generic error message saying there was a problem and I should try again later. In retrospect, I suspect it is related to this.

I believe the error has happened when I made and saved a change in theme settings (Mayo), which prompted a problem connecting type of error. I simply opened a new browser tab and returned to the site and it appeared that all was well and that the change had taken. I'm assuming the error happens because the 777 is needed for the internal workings of Drupal to make and record theme changes. I don't know how big an issue this is.

I appreciate the information and help.

Thanks.

mmjvb’s picture

Suggest to change them to 770 and 660 together with the umask.
Nothing on a webserver requires --7 or --6. When it does, it means it is not properly configured!

See filesystem security.

pheski’s picture

Thank you. I can do that.

Perhaps if I do any future 8.2.5 installs I should change the file that hard-codes them to be created as 777 to 770 to avoid this as a recurrent problem. And perhaps change it in the current install so that new folders and files do not get flagged by my host ISP.

Should I open an issue under core about this? I can't imagine that DreamHost is the only host that scans and complains about 777 directories, or that I am the only person to have been impacted. It would seem the dev team would want to know and would consider a change in an update.

Thank you. I really appreciate the time and expertise here.

P

mmjvb’s picture

Sounds like a proper setting of umask should get you whatever you want on those folders/files.

See https://www.drupal.org/node/2842483

The mkdir 0777 respects the umask, so when properly set (0007) should give you a folder with 770.