Advice on core security issue regarding fileDenyPattern

By: Henning Pingel

Within Security Bulletin TYPO3-20080611-1, the Security Team has informed the public about the dangers of a wrong value of fileDenyPattern in combination with the Apache module mod_mime. This topic is quite complex, so Security Team member Marcus Krause and I decided to discuss further steps on how to deal with the problem within a blog posting. We want to describe how you can force Apache to not execute files with multiple extensions as PHP files in certain directories of a TYPO3 web site. Besides that, we want to give you some examples on how you can check your TYPO3 website for the presence of executable files that shouldn't be executable.

What is this issue all about?

Imagine the following situaton: In a canteen of an IT company, a TYPO3 power user (called B) stumbles into his TYPO3 administrator (called A) at lunchtime. Every time they meet, the power user tries to use this opportunity to stress that he urgently needs more backend user rights:

B: "I really like to work with TYPO3 as a backend user, but I also would love to upload my own PHP scripts: I could code my own reports and simply upload them to fileadmin. This would offer new possibilities for me!"

A: "And that's exactly why it is forbidden. For security reasons, no backend user should be able to upload PHP scripts. Otherwise, the MySQL-password could easily be read from localconf.php, sensitive data is not sensitive any more and other protected page content could be reached or modified. An ordinary backend user would be able to become an admin user!"

B: "Ok, I see. Errr.... So, why don't you give me admin rights straight away? I would even buy you a coffee after lunch."

A: "Hmmm. For how long? How many weeks of free coffee are we talking about?"

We leave this discussion for now, because it probably will go on for a long time, subject being the exact amount of free coffee promised. In the meantime, another backend user (called C) might skip his lunch break to quickly upload a number of important files to fileadmin. One of these files, he has called why.i.like.php.so.much to avoid blanks in the file name for some strange reasons. After accessing the uploaded file via his web browser he notices to his astonishment: The content of the file is not displayed! Will he ever realize that the reason for this is the PHP interpreter jumping into action, expecting the file's content to be PHP code? He will most probably not, but he doesn't intend to start a career as a black hat.

The technical background for this mod_mime related "phenomenon" was already described in the Security Bulletin TYPO3-20080611-1. We recommend to read the bulletin first, if you haven't done it already. Otherwise you may have difficulties to understand the rest of this blog entry.

How to tell Apache to be more strict about files with multiple extensions

One necessary approach to solve this vulnerability is to use a better value with fileDenyPattern within TYPO3. On the other side, another approch could be to modify the Apache configuration (maybe through a .htaccess file on shared webhosting) to make Apache less "sloppy" (from our perspective) when dealing with multiple file extensions. In the unlikely case there are already files existing in your webspace you might consider to force Apache to definitely only treat files as PHP scripts that have a file name with ".php" as final extension.

This will display the content of the files as text/plain:

<FilesMatch "\.php[3456]?\..*$">
    ForceType text/plain
</FilesMatch>

This will deny to access the files via HTTP at all:

<FilesMatch "\.php[3456]?\..*$">
    Deny from all
</FilesMatch>

Make sure that you don't "switch off" PHP files that belong to the TYPO3 system, so don't use the FilesMatch directive in a place where it can affect the contents of the folders typo3, typo3conf or t3lib.

A more general approach to prevent Apache's multiple file type handling would be to unregister PHP file types and only map files based on their last extension to their according handler. In our case putting

RemoveHandler .php .php3 .php4 .php5 .php5 .phps .pht .phtml
RemoveType .php .php3 .php4 .php5 .php6 .phps .pht .phtml

into virtual host configuration or an .htaccess file would make the trick. Then we register the handler again according to the last file extension with

<FilesMatch \.php[3456]?$>
    SetHandler application/x-httpd-php
</FilesMatch>
<FilesMatch \.phps$>
    SetHandler application/x-httpd-php-source
</FilesMatch>

Caution: According to our experiences, when using Debian based Linux distributions, you additionally have to comment/remove the listed PHP mime types from /etc/mime.types. Otherwise the changes above don't have any effect.

How to check if suspicious files exist

If you are unsure if there might already be files within your web space that will be treated as PHP scripts by Apache, you might use the TYPO3 backend Module "DB Check" to search for occurences: Within the module choose "Find filename" and enter regex pattern:

\.php[3456]?(\..*)?$|^\.htaccess$

Note: The contents of the folders typo3, typo3conf and t3lib are excluded from the search.

If you have shell access, you don't need to use TYPO3, you can of course also use commands like this:

find ./fileadmin -type f | egrep '.*\.php[3456]?(\..*)?$'
find ./uploads -type f | egrep '.*\.php[3456]?(\..*)?$'
find ./fileadmin -type f | egrep '/\.htaccess$'
find ./uploads -type f | egrep '/\.htaccess$'

Checking the content of existing .htaccess files does also make sense, because a malicious hacker might abuse .htaccess files to place an AddHandler Directive inside of them to obfuscate the presence of malicious PHP scripts.

Although all these hints are helpful, please keep in mind that they are only examples or impulses and that they are incomplete. A professional malicious hacker will not leave traces at the entrance door. In the end it's the responsibility of the administrator to develop clever methods for intrusion detection that fit the individual server setup.

We hope this blog entry was helpful for you. You can contact the TYPO3 Security Team via http://typo3.org/teams/security/contact-us/ if you have questions.

Henning & Marcus

P.S.: We also hope that administrator A reads this blog entry right after his lunchbreak, before power user B can read it... And, by the way: Maybe you are interested to learn that backend user C doesn't like coffee at all. Why? He gives the reasons in a text file called why.i.dont.drink.coffee which he will upload to fileadmin over a cup of tea. Luckily, since there normally is no "coffee" handler defined, Apache will not send this file to the espresso machine, but only display it in plain text. ;-)

---