13 Oct

security hole for files with a dot at the end

I received an email this morning saying that KFM has a security hole – if a user creates a file named “test.php.” (note the ‘.’ at the end), then it is run as if it was “test.php”, even if you explicitly banned the .php extension in your settings.

I immediately added a line of code to ban all filenames which end in ‘.’, released a new version of 1.3 (available on the front page of the site) and corrected 1.4 in SVN.

After thinking about it, I realised that the security problem is not as serious as it may seem (for KFM – not in general). It’s definitely a problem, but in order to use it, you need to have access to a KFM instance in the first place. As securing KFM is not difficult, I think the problem may be contained.

But I digress – this appears to be a problem in Apache. To test it, I checked if renaming a Perl CGI file from .cgi to .cgi. would work, and it did.

This is a little disturbing, as it does not appear to be documented anywhere, so there is no way that a developer would know to avoid this security hole.

So, if you write programs that allow your users to upload or rename files online, make sure that the filename does not have a ‘.’ at the end!

edit: OMG! I was reading the Apache source to try spot the problem, and found the area where it happens – it’s in the file “http/mod_mime.c”. The function “find_ct()” extracts the extension for the server to use. Unfortunately, it ignores all extensions it does not understand, so it’s not just a case of “test.php.” being parsed as ‘.php’, but also “test.php.fdabsfgdsahfj” and other similar rubbish files! This is a serious problem.

There are a number of solutions to this:

  1. Possibly the correct solution: Keep your downloadables outside the web-accessible area and force the download through a PHP script. Doesn’t matter what extension the file has then.
  2. Tricky but easier to make portable: Write your own extension identifier using the httpd source as a guide, so you know what Apache will identify the file as (annoyingly complex, possibly, but I’ll need to do it…)
  3. Easiest, but most annoying for users: Only allow one ‘.’ per filename.
  4. More difficult, but possibly also correct: Convince Apache that this needs to be fixed, then upgrade immediately when the fix is available.

further update: An easy solution. This problem rears its head when PHP is identified in your httpd.conf using this:

AddHandler php5-script .php

the solution is to change the above to specify the extension must be at the end.

<FilesMatch \.php$>
  SetHandler php5-script
</FilesMatch>

5 thoughts on “security hole for files with a dot at the end”

  1. Arjan -

    This is very disturbing news! Did you already report this to the Apache Foundation or its bugzilla? I think this breaks the security of a lot upload pages.

  2. Kae Verens -

    I reported it to their security mailinglist. I was told that it is a “feature” necessary MultiViews. Personally, I don’t use MultiViews, and would prefer that this “feature” is removed.

    Interestingly, this can be exploited on image-upload scripts which allow images to be viewed from their original file. Simply create a PHP file, rename it “image.php.jpg” and upload it. Apache will treat the file as if it is PHP (not JPG) and will run it… This will probably affect quite a lot of scripts.

  3. Kae Verens -

    I also reported it to the Fedora PHP list and was again told that it is a feature required for MultiViews.

    In short, this will not be fixed ever, so a lot of PHP scripts will need to be rewritten.

  5. Pingback: PHP Parse error: syntax error, unexpected T_STRING in /whatever/my-php-class.php.html on line 1 with PhpDocumentor files on CentOS | SeeIT Consult

Comments are closed.