Christmas Security Alert : php injection


The security flaw

There was no check on the uploaded images in the wiki edit page. Then a malicious user with permission to upload image could upload any php script and call it directly in the tikiwiki file tree, from img/wiki_up/ directory. Actually the flaw is quite trivial, stupid, and obvious. It's rather amazing that nobody fixed it before.


The security cure

Repair your tiki without delay !

Check your tikiwiki sanity


Search for files with extensions .php, .php3, .php4 or .phtml in your img/wiki_up (or img/wiki_up/$tikidomain/ in case of multitiki). You can use the following onelines to find them out (works with multitikis too)

find img/wiki_up -type f -name "*.php" find img/wiki_up -type f -name "*.php3" find img/wiki_up -type f -name "*.php4" find img/wiki_up -type f -name "*.phtml"

Check your apache logs


To find out if someone used that flaw to inject unwanted php file, you can grep your logs (if you can use grep).

grep 'img/wiki_up/[^"]*.ph\(p\(3\|4\)\?\|tml\) ' var/log/apache/yourtiki.access.log

or if your logs are rotated and if you can use zgrep

zgrep 'img/wiki_up/[^"]*.ph\(p\(3\|4\)\?\|tml\) ' var/log/apache/yourtiki.access.log*

Apply a fix


The fastest emergency fix is to disable the "Pictures" feature in the wiki admin panel (/tiki-admin.php?page=wiki).

The alternative inhibition of pictures upload on wiki pages is to limit the feature by setting the tiki_p_upload_picture permission in the groups admin panel.

But for a real fix, and to still be able to include pictures on wiki pages, you need to upgrade or patch the tiki-editpage.php file :

  • CVS users :
    Just update your version, the fix is in all branches from 1.7 to 1.10
    cvs -q update -dP

  • Other users :
    Add the following line in tiki-editpage.php
    if (preg_match('/\.(gif|png|jpe?g)$/i',$picname))

    just before the line containing
    move_uploaded_file( ...
    • with version 1.7.x, on line 106
    • with version 1.8.x, on line 138
    • with version 1.9rcx, on line 173 and 181
    • with version 1.10, on line 172

The sysadmin way

Alternatively (or in more) to the file upgrade/patch, you can inhibit the parsing of php files in the img/ dir.

  • If you use apache, but don't have access to the configuration file, create a .htaccess in img/wiki_up/ containing
    <FilesMatch "\.ph(p(3|4)?|tml)$"> order deny,allow deny from all </FilesMatch>

    if it doesn't work, ask your admin to activate the .htaccess power with
    AllowOverride Limit

    in the Directory directive of your tikiwiki tree. Note that if you use a multi-tiki setup, you'll need to add that .htaccess in each img/wiki_up/$tikidomain subdirectory.

  • If you can change your apache conf because you admin it, add
    <Directory /var/www/tiki/img> <FilesMatch "\.ph(p(3|4)?|tml)$"> order deny,allow deny from all </FilesMatch> </Directory>

    where you need to adapt the path for the directory to match with where is located your img/ dir.

    Both methods above just block the access to php files in img/ directory, but you may also want to inhibit .pl, .vb and other extensions if your global configuration enables those extensions to be parsed by another preprocessor.


New releases with a fix


In each released branch a new version is available, namely 1.7.9, 1.8.4.1 and 1.9rc3.1. If you didn't apply one of the solutions listed above :

you should upgrade as soon as possible.

Download here!

Remember that you always can alert the tikiwiki security group by sending a mail to security at tikiwiki.org.


mose,
for the Tikiwiki Security Bunch-of-people