Lucene search

K
seebugRootSSV:72432
HistoryJul 01, 2014 - 12:00 a.m.

Tiki Wiki CMS Groupware <= 8.2 (snarf_ajax.php) Remote PHP Code Injection

2014-07-0100:00:00
Root
www.seebug.org
22

0.015 Low

EPSS

Percentile

85.4%

No description provided by source.


                                                  -------------------------------------------------------------------------
  Tiki Wiki CMS Groupware &#60;= 8.2 (snarf_ajax.php) Remote PHP Code Injection
  -------------------------------------------------------------------------
  
  author...........: Egidio Romano aka EgiX
  mail.............: n0b0d13s[at]gmail[dot]com
  software link....: http://info.tiki.org/
  
  
  [-] Vulnerability explanation:
  
  The vulnerable code is located into /lib/wiki-plugins/wikiplugin_snarf.php:
  
  170.   // If the user specified a more specialized regex
  171.   if ( isset($params[&#39;regex&#39;]) && isset($params[&#39;regexres&#39;]) && preg_match(&#39;/^(.)(.)+\1[^e]*$/&#39;, $params[&#39;regex&#39;]) ) {
  172.      $snarf = preg_replace( $params[&#39;regex&#39;], $params[&#39;regexres&#39;], $snarf );
  173.   }
  
  input passed through $_REQUEST[&#39;regex&#39;] is checked by a regular expression at line 171 to prevent
  execution of arbitrary PHP code using the  &#39;e&#39;  modifier in a call to preg_replace() at line 172.
  But  this  check  could  be  bypassed  with a  null byte injection,  requesting an URL like this:
  
   http://&#60;hostname&#62;/tiki-8.2/snarf_ajax.php?url=1&regexres=phpinfo()&regex=//e%00/
  
  Tiki internal filters remove  all null bytes  from user input,  but for some strange reason  this
  doesn&#39;t  happen within admin sessions. So, successful exploitation of this vulnerability requires
  an user account with  administration  rights and  &#39;PluginSnarf&#39;  to be enabled  (not by default).
  
  
  [-] Disclosure timeline:
  
  [23/11/2011] - Vulnerability discovered
  [24/11/2011] - Issue reported to security(at)tikiwiki.org
  [24/11/2011] - New ticket opened: http://dev.tiki.org/item4059
  [27/11/2011] - Vendor confirmed the issue
  [27/11/2011] - CVE number requested
  [28/11/2011] - Assigned CVE-2011-4558
  [22/12/2011] - After four weeks still no fix released
  [23/12/2011] - Public disclosure

                              

0.015 Low

EPSS

Percentile

85.4%