Apache Multiple Extension vulnerability

[iago]

I was vulnerable to this until recently.  I fixed it, and posted to Full disclosure, and apparently it's not commonly known.  Here's the full post:

I'm not sure whether this is something that's well known, but I've never seen anything about it, and I nearly got burned by it, so I figured I'd post it here.

In Apache 1.3.33 (untested on any other version), if you have a file called file.php.bak, and you navigate to it in the browser, it will run on the server as a .php file.  This works with any extension that isn't known to the server (.rar, .bak, .test, .java, .cpp, .c, etc.)

This can impact upload scripts, if they don't rename.  I had a script that was only allowing a very limited number of file names, including .rar.  I realized that I could upload the file test.php.rar, as demonstrated here:
http://www.javaop.com/~iago/test.php.rar

(I assure you that that's a .php script, not just that text file).

Resolution: If any script does that, it should be changed such that it renames any files, perhaps to a SHA1() hash of the filename, or a timestamp, or anything like that.

This problem reminds me of a recent discussion about files like file.exe.txt in Windows.

In general, that's good advice anyways, you shouldn't allow any kind of user specific filenames.  But just in case somebody is making this mistake, be careful!   As I said, I nearly got burnt by this, luckly I noticed it before anybody malicious did.

Ron
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Here's the full thread, if you want to read responses:

http://seclists.org/lists/fulldisclosure/2005/Dec/0170.html

<edit> update: here are some more observations I made:

Simon Richter wrote:
> I would think this is related to "Options MultiViews", where a file
> generally has many suffixes (file type, language, compression, ...).
> Does this also happen to you (yes, I'm too lazy to try right now) if you
> turn MultiViews off?
>
> Nevertheless, good idea that script authors should possibly be aware
> that any suffix, not just the last, is interpreted.
>
>    Simon

Thanks for the response,

That was a good idea, I hadn't thought of it; however, I turned off MultiViews, and it still behaves the same way.

I also tried adding more extensions, just out of curiosity.  The following files also run as .php files:
  http://www.javaop.com/~iago/test.php.cpp.java
  http://www.javaop.com/~iago/test.php.a.a.a.a.b.b.b.b.c.d.e.f

Interestingly, these files are NOT affected, and don't parse the .php:
  http://www.javaop.com/~iago/test.php.jpeg.bmp.rar
  http://www.javaop.com/~iago/test.php.jpeg.rar

The first of those two behaves as a .bmp, and the second one behaves as a .jpeg.

It seems that it uses the last recognized extension when parsing files, ignoring everything after it.

Any other ideas?  At this point, I'm unsure whether to call it a bug or a feature, and whether to alert Apache about it.  Unless somebody posts soon, I'll send a bug report to Apache.

Ron

[Sidoh]

We rule.

[Joe]

Go iago! Full discloser for the win~.

[Sidoh]

Go iago! Full discloser for the win~.

Disclosure *.

[iago]

Nobody cares about spelling, damnit!  Any spelling post is a waste of a post, and of my time. 


In other news, this is a known feature of Apache:

Not only is it a feature, it's documented:
<http://httpd.apache.org/docs/2.0/mod/mod_mime.html>
The docs note that the rightmost extension for a paricular category of meta data is used.  The exeption is languages and encodings, where they accumulate instead.
Unknown extensions contribute nothing, and since they're unknown, it isn't known which category they aren't known for, so nothing happens with them.
So, anything dealing with Apache-served files must not look only at the file's suffix, but all positions.
To secure the user-upload area discussed earlier, you need to do one of:
- Sanitize to a known set of extensions and only allow known-valid groups of content, languate, and encoding extensions.  (So .tar.gz is fine, but .php.gz is probably bad.)
- Disable PHP for the upload area (is this possible?  I don't use PHP myself)
- Use ForceType to set a particular type.  You've still got to worry about extension-based (instead of type-based) handlers and things link that.
- Put up the AddTypes for PHP types only in known-php directories.   In this case, you would want your user upload area to be in a totally different place from your DocumentRoot so you don't get anything set on DocumentRoot leaking into the writable subdirectory.  (That's a good idea in general, of course; any server directory with a different security policy from DocumentRoot should be somewhere other than under DocumentRoot.)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

It's still something that people should be aware of, but gg :-o

[Sidoh]

Nobody cares about spelling, damnit!  Any spelling post is a waste of a post, and of my time. 

I'm saving him the future embarassment! :]

[iago]

It looks like the only reason you're doing that is an attempt to make him look bad.  I commonly see people picking at others like that, and it bugs me. 

Anyway, another post regarding it (I'm creating a little noise, go me!):

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

z3n wrote:
> > Great Bug indeed!
> >
> > But don't you think this issue is kind of similar to issue 3 in this
> > (old) advisory:
> > http://archives.neohapsis.com/archives/bugtraq/2003-01/0203.html

Indeed it appears that 2.0.44 did not completely plug the misdocumented
path processing behavior described in my January 2003 advisory.

This is due to an obscure, misdocumented "feature" in Apache that causes
the server to process the last "valid" extension in the path.  This
behavior is (at least in 2.0) very dangerous and very badly implemented.
 In some conditions, Apache will parse folder names looking for
extensions, and even extraneous path information is sometimes parsed by
the server's handler-mapping routines.

If what I've been reading in other posts on the list is accurate, it
appears that at least some of this file/folder name handling behavior is
also seen in 1.3.x series releases.

I'd expect scores of apps to be vulnerable to attack in this fashion, as
the overwhelming majority of CMSes that allow file uploads use
user-supplied file names, and few of them check for double-extensions.

Counter-measures:

1. Use (as other posters suggested) an auto-generated file name, rather
than the user-supplied filename.  For instance:

username-sha1hashs.extension

which would produce something like:

mattmurphy-345f... .jpg

Obviously you still have to sanity check the extension (and the file
itself if IE 6.0 users are going to be visiting your site) to ensure
that it is a legitimate uploaded file you are accepting.

2. Use a "fetch" script.  Place your uploads outside the document root
or in a folder that has these directives in an .htaccess:

   Order Allow,Deny
   Deny from All

And have a script for accessing uploaded files which returns the content
of these otherwise inaccessible files.  For example (PHP):

<?php
$mime_types["png"]  = "image/png";
$mime_types["jpg"]  = "image/jpeg";
$mime_types["jpeg"] = "image/jpeg";
$mime_types["gif"]  = "image/gif";
$mime_types["bmp"]  = "image/bmp";

// Sanity-check entered file path to avoid security holes (directory
// traversal, etc.)

$pattern = '/^(\w+)(\.)(\w+)$/';
$fn = $_GET["name"];
$path = "uploads/$fn";
if (!preg_match($pattern, $fn) || !file_exists($path)) {
   die("Invalid file path specified!");
}

// Drop the file with the relevant MIME type.  Assumes that image is
// valid.  This check should be done by an upload script to avoid
// compromising users' systems if they visit your site with Microsoft's
// Internet Explorer Bugware:
//
// http://seclists.org/lists/fulldisclosure/2005/Oct/0494.html

$ext = substr($fn, strpos($fn, "."));
header("Content-Type: ".$mime_types[$ext]);
print file_get_contents($path);
?>

This may have bugs, but you get the idea.

3. Disallow Content Execution from Within Upload Directories

In order to do this, include the following directives in a location
container or .htaccess:

    Options    -ExecCGI
    SetHandler default-handler
    ForceType  text/plain

    <FilesMatch "\.(gif|.jpe?g|png)$">
    ForceType  None
    </FilesMatch>

You may choose to add more file extensions to the FilesMatch and you may
also use explicit AddType directives to ensure that legitimate uploaded
file types are given their proper MIME types when downloaded from the
server.

This remarkably simple step can prevent users from dropping content into
your uploads directory and running it on your server.  However, it
doesn't get around the a serious hole in IE that could compromise the
systems of your visitors:

http://seclists.org/lists/fulldisclosure/2005/Oct/0494.html

It's pretty pathetic that web app developers have to code around
security holes in a browser to protect their users, but such is a fact
of life in the case of IE.

The first two steps are aimed more at application developers, while the
third is intended more as a stopgap measure that admins can use to deal
with the risks of sloppy application design.

The moral of this story: don't use direct user input, even seemingly
valid input, if you don't have to.

- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."

                                -- Michael Holstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDliUrfp4vUrVETTgRAwCmAJ9VsZTjdkuJ9p2kGEjP2T6D1pGGeQCfWoB1
5whkFco/qIzcihsPFJ8hXe8=
=GbA5
-----END PGP SIGNATURE-----



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

[Sidoh]

It looks like the only reason you're doing that is an attempt to make him look bad.  I commonly see people picking at others like that, and it bugs me. 

For some strange reason, I thought discoloser was a word; that's why I corrected him on it.  I was thinking he thought the name of Full Disclosure was Full Discloser, which is why I corrected him.  It was in no way a way to make him look bad.