Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix upload filter bypass leading to RCE #49

merged 1 commit into from Oct 13, 2019


Copy link

rastating commented Oct 12, 2019

It is possible to bypass the media asset upload restrictions that are in place to prevent arbitrary PHP being executed on the server by abusing a combination of two issues.

The first is the support for uploading animated GIFs. By submitting a GIF that contains the following content we can place a GIF file that contains [currently unexecutable] PHP code in a GIF file on the server (in this case test.gif):

GIF89a; <?=`$_GET[1]`?>

After uploading this, the file can now be clicked and the move function can be used to move this into another directory within the application directory with a PHP extension (in this case, it is moved to tmp/media_thumb/shell.php):


As can be seen in the below screenshot, this is now stored on the server with a valid extension:


At this point, the PHP file cannot be executed as the htaccess file found in tmp/.htaccess contains the following configuration:

<Files *.php>
deny from all

This prevents any PHP files under tmp/ being accessed. However, the same upload vulnerability can be abused to overwrite the htaccess file. To do this, one uploads a GIF file again but with the content:

# GIF89a;

This creates a GIF file on the server, that starts with a valid comment character, which prevents the server running into an error when parsing it during subsequent requests. The same rename bug can then be used to move this file to tmp/.htaccess:


After doing this, the PHP file can be accessed from the web browser, and remote code execution is gained as can be seen in the below screenshot in which cat /etc/passwd is executed:


This pull request implements a rather simplistic means of patching this for now, by checking the extension of the specified destination path and blocking it if it is either php or htaccess. Ideally, a more robust solution should be put in place in the long term by creating a valid white list of safe extensions, but for now, this should mitigate the immediate threat.


This comment has been minimized.

Copy link

vzuburlis commented Oct 13, 2019

That was good. Never though of renaming htacces files.
Thanks for your contribution

@vzuburlis vzuburlis merged commit 9fa8ab2 into GilaCMS:master Oct 13, 2019

This comment has been minimized.

Copy link
Contributor Author

rastating commented Oct 13, 2019

You're welcome! It should be noted that there is still potential for abuse by using a blacklist vs a white list of safe extensions.

Although I believe the default configuration of Apache / PHP adds handlers for extensions such as php4 and php5, these may still be present in some users' configurations. So, ideally, it'll be locked down to only allowed specific extensions rather than allowing everything except .php and .htaccess

It's more of an edge case scenario nowadays, but it's worth trying to fix it at some point in the future when time permits 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.