lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 16 Dec 2004 17:21:07 -0000
From: "Richard Stanway" <bugtraq@...ur1ty.net>
To: <bugtraq@...urityfocus.com>
Subject: RE: STG Security Advisory: [SSA-20041215-17] Vulnerability of    uploading files with multiple extensions in JSBoard


Hi,

> ...
> This
> is originated from a feature of Apache MIME module (mod_mime),
> which regards
> attack.php.hwp as a normal PHP file and execute the file through mod_php
> module with the privilege of the HTTPD process.
>
> cf. http://httpd.apache.org/docs/mod/mod_mime.html - "Files with Multiple
> Extensions" : it's a feature, not a bug.
>

I'd like to follow up on this as I've done a bit of research onto this
"multiple extensions" behaviour in the past. I was however unaware that
having extensions on the end that aren't registered MIME types will also
cause code execution, but after looking through mod_mime.c it is quite clear
it's possible. There are a huge number of 3rd party PHP scripts out there
that are unaware of the "multiple extensions" behaviour and thus could be
vulnerable to this issue. Most of them do have a simple extension checks
though for files such as .jpg .png .gif etc so the chances of being able to
upload a file without a registered MIME type are somewhat reduced.

As a rather ugly "fix", I have patched Apache to remove the multiple
extensions behaviour for handlers (AddHandler) as there seemed no legitimate
reason why it would be needed. If anyone is interested, the patch is
available at http://secur1ty.net/mod_mime-handler-lastonly.patch and applies
cleanly to the 1.3.3x series and I have been using this patch for over a
year in production use without any problems. This begs the question, is
there any legitimate use or need for "handlers" to be invoked on every
extension? For "index.en.html" and such I can understand why multiple
extensions are used for MIME type purposes, but is there any such practical
use for handlers?

If not, why then does PHP use a MIME type to execute by default instead of a
handler? It appears to work equally well when the AddType is changed to
AddHandler in the httpd.conf, and similar items (server-parsed, cgi-script)
are added as handlers by default. Since multiple MIME types are legitimately
used and multiple handlers have questionable use, would it not make sense to
have handlers only invoke on the last extension and have PHP and other
scripting language modules execute as handlers?

The risks may also be increased on servers using cPanel, a popular web
hosting control panel that has the option of using PHP as a CGI under suExec
to aid in auditing and file permissions issues. The cPanel developers have
purposefully removed the need for PHP CGI files to be +x, and since CGI is
used as a handler, any file.php.ext on a PHP-CGI enabled cPanel server will
be executed, regardless if .ext is a registered MIME type which would
otherwise mitigate the problem. The developers have confirmed this is the
intended behaviour in order to "make it easier for users". Again, this would
not be a problem if handlers weren't invoked on every extension.

I contacted the Apache security team over a year ago about the various
issues with the mod_mime.c processing of multiple extensions but did not
receive a reply. I would also like to point out an article I wrote about
handling file uploads and dynamic content, this should be recommended
reading for any 3rd party script coders who use file uploads as it has a
section about multiple extensions as well as other pertinent issues. You can
read it at http://shsc.info/FileUploadSecurity.

I'd appreciate any feedback about the handler issue as I really don't see
why it's needed and it seems like a good way to fix the problem rather than
have thousands of vulnerable PHP scripts on the loose.

Rich.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ