Date: Tue Dec  6 23:56:45 2005
From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Bug with .php extension?

-----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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3436 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051206/9ccbc480/smime.bin

Powered by blists - more mailing lists