Take for instance this code saved as test.php.png
1 2 3 |
Low and behold this will render out the entire post array! and will interpret the php itself, now lets be clear here the proper use of selinux and directory structures to prevent UGC from being allowed to be access directly and / or run arbitrary code would of prevented this, however as is often the case the setup is such that the preventative conditions could not / are not deployed.
At any rate this bug comes courtesy of the apache AddHandler directive,
1 | AddHandler x-httpd-php .php |
The statement above seems to ‘loose’ match the .php extension meaning a file simply only contain .php anywhere in it’s filename to be interpreted as PHP.
The suggested work around for this is as follows:
1 2 3 4 5 | #Workaround for bug here: https://bugzilla.redhat.com/show_bug.cgi?id=537535 <FilesMatch \.php$> SetHandler x-httpd-php ForceType text/html </FilesMatch> |
Note this does not effect the AddType directive, after testing on the same version using:
1 | AddType application/x-httpd-php .php |
Is not effected by this ‘bug’.
Tags: 537535, Apache, dual extension, php, vulnerability
Entries (RSS)