[dokuwiki] Re: fixing clientIP(), Exploit details

  • From: Chris Smith <chris@xxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Fri, 08 Sep 2006 15:52:57 +0100

burt wrote: 

So as to understand, to reiterate the quick fix,

These two exploits are serious attacks on dokuwiki:

http://www.milw0rm.com/exploits/2321
http://www.milw0rm.com/exploits/2322

The longer attack, 2311 operates:

(1) Use X-FORWARD-FOR: _inject_string_ during a do=edit post to create a lock file with _string_ in the lock file.

(2) Use GET bin/dwpage.php?_another_diabolical_string to move the lock file, giving it a php extension
This seems to take two steps., "commit" and "checkout"

(3) GET using the CLIENT-IP: _command_to_run_ to run the _inject_string_ with argument _command_to_run_

I really do expect myself to understand this completely, but I hope this is the basic idea.

*And the outcome is*

in the short term, prevent the running of bin/dwpage.php by creating bin/.htaccess containg the two lines:

Order deny,allow
Deny from all

The web server does not need to be restarted, I believe.

However, this doesn't entirely neutralize the attack, it just stops one implementation of it ...

Correct? 
Not entirely.

There is a flaw in the current release version enabling X_FORWARD_FOR contents to be saved to a lock file. This isn't serious as these files are ostensibly innoccuous, whatever their contents[1].

The flaw is in the dwpage.php in:
(a) it can be run remotely
(b) if run remotely it allows any files that are readable by the webserver userid to be copied into the wiki, thereby enabling them to be viewed by dokuwiki. This may result in garbage.
(c) if run remotely it allows files from within the wiki to be copied anywhere the webserver has write access. This allows files to be copied to places where they can be exploited. eg. if they are copied to other locations accessible by the webserver they can be
- viewed outside of DokuWiki's ACL system
- run as scripts, e.g. if the file is a valid php script and its given a ".php" extension.

When (b) is combined with (c), a script or file that is not normally accessible over the web can be made accessible/executable.

(c) is a particular problem as DokuWiki has no real restrictions on the content that can reside in the raw wiki files - which are stored as accurate representations of the entered data. This means, for example, an entire php script can be saved as a wiki page then using dwpage.php remotely it can be copied to a place where it can be executed by the webserver.

All of these flaws are prevented if dwpage.php can not be run remotely. The .htaccess fix achieves that for any server that recognises .htaccess files and the Order & Deny directives.

I believe the fix I posted earlier today will prevent the problem occuring on all webservers, although more testing would be required to prove that.

Cheers,

Chris

[1] A lock file will only be created if a wiki page is editable by that user. So although it is possible to inject malicious code into the lock file it would be much easier to save that code in the editable wiki page. It may well be, that by using the lock file you are able to hide your activities from easy detection.
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts:

  1. Home
  2. dokuwiki
  3. Archive
  4. 09-2006