#1402 ✓resolved

Security? Unrestricted File Upload Vulnerability in expFile.php

Reported by mm | December 11th, 2016 @ 08:47 PM | in 2.4.1 (closed)

Allows unauthenticated users to upload executable files.

curl -F "upload=@/attack.php" [exponent]/framework/modules/file/connector/uploader.php

Comments and changes to this ticket

  • dleffler

    dleffler December 12th, 2016 @ 07:24 PM

    • State changed from “new” to “invalid”
    • Assigned user cleared.
    • Milestone set to User issues

    This condition can NOT exist in recent versions, esp v2.4.0 plus patches since uploaded (php) files can NOT be executed (on apache based servers). Yes the file can be uploaded, but not executed.

  • mm

    mm December 12th, 2016 @ 11:44 PM

    I disagree. This condition exists right now on exponentcms.org.

    I checked out the master branch https://github.com/exponentcms/exponent-cms/tree/master, installed it on Apache/2.4.18 (Ubuntu) running PHP 7.0.8 and was able to upload executable PHP files.

    "AllowOverride" is set to "All".

    Loaded Modules:
    core_module (static) so_module (static) watchdog_module (static) http_module (static) log_config_module (static) logio_module (static) version_module (static) unixd_module (static) access_compat_module (shared) alias_module (shared) auth_basic_module (shared) authn_core_module (shared) authn_file_module (shared) authz_core_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) filter_module (shared) mime_module (shared) mpm_prefork_module (shared) negotiation_module (shared) php7_module (shared) setenvif_module (shared) status_module (shared)

    Might be relevant: https://blog.remirepo.net/post/2013/01/13/PHP-and-Apache-SetHandler...

    Actually, the .htaccess file shouldn't be necessary at all since you already have a whitelist of allowed extensions in the code.

    But it doesn't work, due to errors e.g. in line 442 in framework/modules/file/models/expFile.php:
    $handle->file_new_name_ext = ''; which prevents checks for malicious file extensions later on in line 3051 in framework/modules/pixidou/includes/class.upload/class.upload.php:
    if (!is_null($this->file_new_name_ext)) { // rename file ext

    Also, the (IMHO dangerous) .htaccess blacklist approach used by FilesMatch is missing PHP extensions such as ".php5".

  • dleffler

    dleffler December 13th, 2016 @ 01:09 AM

    • Title changed from “Exponent CMS 2.4.0 Patch 5 - Unrestricted File Upload Vulnerability in expFile.php” to “Security? Unrestricted File Upload Vulnerability in expFile.php”
    • State changed from “invalid” to “open”
    • Tag set to security, uploader
    • Milestone changed from User issues to 2.4.1

    First, the .php5 (&.php7) extension issue was actually addressed earlier today in the pre-release code for the next patch/release.

    The class.upload.php is a 3rd party library used by the deprecated File Manager/Pixidou editor, which we piggy-backed on to perform image resize on upload (prior to the implementation of the new file manager elFinder). I also believe that the code in class.upload.php (to which you refer) is not used to filter filetypes, but to convert images and ensure the correct filetype is output? We do have a couple of different 3rd party libraries and even methods within expFile which might be suitable for our image resizing on upload (elFinder has it built-in)

    Perhaps it would be good to add optional file upload by filetype blacklisting but it would also require tying it to several pieces of code to become a system wide implementation and prevent file uploads using the many methods we currently support.

  • mm

    mm December 13th, 2016 @ 07:25 PM

    Since I saw the recent commits:

    The .htaccess file extension blacklist is not the right way to fix this vulnerability.

    It might work for you / your specific apache configuration. But:

    • If you would follow the PHP recommendations on how to configure apache (http://php.net/manual/en/install.unix.apache2.php), it won't work.

    • If you run Ubuntu (<FilesMatch ".+.ph(p[3457]?|t|tml)$">SetHandler application/x-httpd-php</FilesMatch>), it won't work any more.

    • If you run on a restrictive webhoster (AllowOverride None), it won't work.

    • ...

    Conclusion: As long as you don't add your specific apache configuration to the installation requirements, blacklists just won't work. Whitelists are the only way to go (see e.g. Wordpress).

    Regarding pixidou:

    If configured properly, it matches file names against a build-in blacklist in an attempt to prevent executable files from being uploaded. See e.g. line 2945: preg_match('/.(php|php5|php4|php3|phtml|pl|py|cgi|asp|js)$/i', $this->file_src_name).

    Still, as this is a blacklist and blacklists are generally insecure, it won't solve anything.

  • expNinja

    expNinja December 14th, 2016 @ 07:45 PM

    • State changed from “open” to “resolved”

    (from [0dd7790352cabef4637ac826f22755038ffac152]) integrate class.upload to help process all file uploads and filter executables; moves class.upload from pixidou to /external; filters uploads through elFinder to same mime types as class.upload; better error response to XHR upload [#1402 state:resolved] https://github.com/exponentcms/exponent-cms/commit/0dd7790352cabef4...

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Bug Tracker for Exponent CMS

Shared Ticket Bins

People watching this ticket

Referenced by