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)

Copy to clipboard
  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).

Copy to clipboard
  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

Copy to clipboard
  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
    Copy to clipboard
    cvs -q update -dP

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

    just before the line containing
    Copy to clipboard
      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
    Copy to clipboard
      <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
    Copy to clipboard
      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
    Copy to clipboard
      <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