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)

~np~  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"~/np~

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).

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

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

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
  

  ~np~  if (preg_match('/\.(gif|png|jpe?g)$/i',$picname))~/np~

  
  just before the line containing
  

  ~np~  move_uploaded_file( ...~/np~

  • 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
  

  ~np~  <FilesMatch "\.ph(p(3|4)?|tml)$">
      order deny,allow
      deny from all
    </FilesMatch>~/np~

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

  ~np~  AllowOverride Limit~/np~

  
  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
  

  ~np~  <Directory /var/www/tiki/img>
      <FilesMatch "\.ph(p(3|4)?|tml)$">
        order deny,allow
        deny from all
      </FilesMatch>
    </Directory>~/np~

  
  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.

• Read more on http://httpd.apache.org/docs-project/

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