Disable multiple file extension support?

[Rich Bowen <rb...@rcbowen.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The folks at Drupal have apparently just discovered that
something.php.bar is executed as PHP, and, thus, checking to see if a
file ends with .php is not sufficient to ensure that their file upload
feature can't be exploited.

In fact, they have a whitelist, and check to see the files end only with
stuff on the whitelist, so it's a little more robust than that, but
still fairly easy to get around.

I've been asked to pass on a request for a configuration directive to
disable the support for multiple file extensions - that is, ensure that
only the final file extension is honored when determining how to handle
a file.

I haven't thought though all the implications of such a directive, nor
do I know how feasible it is. But I've passed on the request.

- --Rich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdlUdXP03+sx4yJMRAoNjAJ4u5ZWisCH/tvp815nDWV5nsVlN8QCfdFC1
xObWe9eolhXx0ila5ucjfOY=
=OlDX
-----END PGP SIGNATURE-----

Re: Disable multiple file extension support?

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Rich Bowen wrote:
> 
> The folks at Drupal have apparently just discovered that
> something.php.bar is executed as PHP, and, thus, checking to see if a
> file ends with .php is not sufficient to ensure that their file upload
> feature can't be exploited.

Their file upload feature can likely be perpetually exploited, but that's
neither here nor there...

> In fact, they have a whitelist, and check to see the files end only with
> stuff on the whitelist, so it's a little more robust than that, but
> still fairly easy to get around.

The only valid manner of configuring such a server is to cripple all
multiviews and negotiation in the 'uploads directory' (preferably NOT
by removing behaviors additively, but by staging uploads outside of such
negotiated directories, e.g. /server/uploads alongside /server/htdocs).

The line endings are only the beginning of the long list of vulnerabilities
in this scenario.  Adding '.txt' at the end of such names is an ineffectual
hack.  If the directory is listable the site becomes XSS vulnerable.  Even
if all else were equal, all handlers and filters would have to be defined
by content type, the mime.types as defined for the web space would have to
be used as the whitelist, and the filenames need to be parsed for all file
extentions segments.  Why bother?  Options None is probably their friend
for such purposes.

> I've been asked to pass on a request for a configuration directive to
> disable the support for multiple file extensions - that is, ensure that
> only the final file extension is honored when determining how to handle
> a file.

There are several.

  1. disable mod_mime / mod_negotiation
  2. disable Options Multiviews, and a host of other Options, in '/uploads'.
  3. MultiviewsMatch to refine behavior if multiviews are enabled
  4. SetHandler default-handler absolutely in the .htaccess or <Directory >
     to override everything negotiated (won't cripple filters, only handlers.)

I'll veto yet-another-option, because more options imply more ways to get
it wrong.

> I haven't thought though all the implications of such a directive, nor
> do I know how feasible it is. But I've passed on the request.

Nak'ed :)

Bill

Re: Disable multiple file extension support?

[Rich Bowen <rb...@rcbowen.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Ionescu wrote:
> Rich Bowen wrote:
>> Joshua Slive wrote:
>>> <FilesMatch \.php$>
>>> SetHandler php-script
>>> </FilesMatch>
>>> (in place of any other method of activating php)
> [...]
>> That only works if you happen to be the server administrator. If,
>> however, you are renting web space from someone who has php enabled
>> globally (this appears to be the normal Drupal user) that's not going to
>> solve anything.
> 
> And what about
> 
> RemoveHandler .php
> <FilesMatch \.php$>
> SetHandler php-script
> </FilesMatch>
> 
> That works at least for me while something.php.bar displays now as
> text/plain.

Note that the php example was only one of many possible examples. Any
solution will also need to cover .pl .cgi. .py .sh and on and on and on.
Solutions that only address .php aren't really solutions. I just used
that as an example.

- --Rich
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEevIQXP03+sx4yJMRAqhJAKDFvvjYe2OAsJ6Ml4JphIpnAaTsPgCg9IOY
rzJ/wouj9bKMZpUwHanfIps=
=UUQK
-----END PGP SIGNATURE-----

Re: Disable multiple file extension support?

[Robert Ionescu <ro...@googlemail.com>]

Rich Bowen wrote:
> Joshua Slive wrote:
>> <FilesMatch \.php$>
>> SetHandler php-script
>> </FilesMatch>
>> (in place of any other method of activating php)
[...]
> That only works if you happen to be the server administrator. If,
> however, you are renting web space from someone who has php enabled
> globally (this appears to be the normal Drupal user) that's not going to
> solve anything.

And what about

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

That works at least for me while something.php.bar displays now as 
text/plain.

-- 
Robert

Re: Disable multiple file extension support?

[Rich Bowen <rb...@rcbowen.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joshua Slive wrote:
> On 5/25/06, Rich Bowen <rb...@rcbowen.com> wrote:
>> The folks at Drupal have apparently just discovered that
>> something.php.bar is executed as PHP, and, thus, checking to see if a
>> file ends with .php is not sufficient to ensure that their file upload
>> feature can't be exploited.
>>
>> In fact, they have a whitelist, and check to see the files end only with
>> stuff on the whitelist, so it's a little more robust than that, but
>> still fairly easy to get around.
>>
>> I've been asked to pass on a request for a configuration directive to
>> disable the support for multiple file extensions - that is, ensure that
>> only the final file extension is honored when determining how to handle
>> a file.
>>
>> I haven't thought though all the implications of such a directive, nor
>> do I know how feasible it is. But I've passed on the request.
> 
> You can pass back
> <FilesMatch \.php$>
> SetHandler php-script
> </FilesMatch>
> (in place of any other method of activating php)
> 
> Yes, this confuses many people who aren't used to the fact that a file
> can have more than one extension.  But I believe it is easy enough to
> deal with when you know about it.  Given the existence of
> <FilesMatch>, I don't think we really need to add an option to
> AddHandler/AddType/etc.

That only works if you happen to be the server administrator. If,
however, you are renting web space from someone who has php enabled
globally (this appears to be the normal Drupal user) that's not going to
solve anything.

The discussion seems to be leaning the direction of trapping the file
when it is uploaded and defanging it at that point.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEdmKpXP03+sx4yJMRAgu0AJ91vS+9LsLDPtVvF29BtkuW4lBwhwCfR7dp
KVQKmFqCjLXMgHwij2t5cfM=
=91uD
-----END PGP SIGNATURE-----

Re: Disable multiple file extension support?

[Joshua Slive <jo...@slive.ca>]

On 5/25/06, Rich Bowen <rb...@rcbowen.com> wrote:
> The folks at Drupal have apparently just discovered that
> something.php.bar is executed as PHP, and, thus, checking to see if a
> file ends with .php is not sufficient to ensure that their file upload
> feature can't be exploited.
>
> In fact, they have a whitelist, and check to see the files end only with
> stuff on the whitelist, so it's a little more robust than that, but
> still fairly easy to get around.
>
> I've been asked to pass on a request for a configuration directive to
> disable the support for multiple file extensions - that is, ensure that
> only the final file extension is honored when determining how to handle
> a file.
>
> I haven't thought though all the implications of such a directive, nor
> do I know how feasible it is. But I've passed on the request.

You can pass back
<FilesMatch \.php$>
SetHandler php-script
</FilesMatch>
(in place of any other method of activating php)

Yes, this confuses many people who aren't used to the fact that a file
can have more than one extension.  But I believe it is easy enough to
deal with when you know about it.  Given the existence of
<FilesMatch>, I don't think we really need to add an option to
AddHandler/AddType/etc.

(I'm trying not to comment about the general wisdom of having a
file-upload area that has any kind of dynamic processing enabled in
any way...)

Joshua.