Bugzilla Bug 135623

DokuWiki comes with an AJAX spellchecking service that can be
   called by every visiting client without the need of authorization.

   Unfortunately the spellchecking service used the /e modifier of
   preg_replace() to handle links that are embedded in the text to
   translate in an unsafe way.

      // don't check links and medialinks for spelling errors
      $string = preg_replace('/\{\{(.*?)(\|(.*?))?(\}\})/e',
                             'spaceslink("\\1","\\2")',$string);
      $string = preg_replace('/\[\[(.*?)(\|(.*?))?(\]\])/e',
                             'spaceslink("\\1","\\2")',$string);

   Therefore it is possible to request a spellcheck for a string like

      [[{${phpinfo()}}]]

   which will result in the evaluation of something like

      spaceslink("{${phpinfo()}}",...);



http://www.hardened-php.net/advisory_042006.119.html

web-apps please advise and provide an updated ebuild as necessary.

Here is a new one... mail taken from the dokuwiki list:


Hi *!

Just send to the announcement list. BTW: Is everybody fine with me
copying the security announcements here? Or would you prefer getting
them via freshmeat only?

----

Just two days after the last security problem another flaw was
discovered. Luckily not as bad as the last one.

Andreas 

Here is a new one... mail taken from the dokuwiki list:


Hi *!

Just send to the announcement list. BTW: Is everybody fine with me
copying the security announcements here? Or would you prefer getting
them via freshmeat only?

----

Just two days after the last security problem another flaw was
discovered. Luckily not as bad as the last one.

Andreas Åkre Solberg discovered a security flaw which allows registered
users to view page content they usually have no access to. The problem
is in the way how a successful user profile change is handled.

This affects only installs which have Access Control Lists enabled (off
by default) and restricted the READ permission for certain pages even
for logged in users. Non-authenticated users can not exploit this bug.

The package available at http://www.splitbrain.org/go/dokuwiki was
updated again to reflect the change but fixing it manually is simple,
too. Info on how to do this is available at
http://bugs.splitbrain.org/?do=details&id=825

Andi

PS: I apologize for the trouble. Unfortunately the bigger and complex a
software gets the more likely security flaws are. I try hard to avoid
common mistakes but sometimes a bug slips through. If you are an
experienced PHP developer I encourage you to have a look at the code
(preferably the devel code) your self to help spotting such weaknesses -
the more people check, the better it gets.

I'm fine with that. I personally chose DokuWiki for the non-dependance on a DB
and I like it a lot. It's got its flaws like any other app, but it's definitely
a "way to go" I support. Guess I'm in for some contribution sooner or later .-)

If maintainers ever falls short on this one, page me :D

I'm fine with that. I personally chose DokuWiki for the non-dependance on a DB
and I like it a lot. It's got its flaws like any other app, but it's definitely
a "way to go" I support. Guess I'm in for some contribution sooner or later .-)

If maintainers ever fall short on this one, page me :D

Bumped, as dokuwiki-20060309-r1.  x86 will need to stabilise, so that we can
remove dokuwiki-20050922.

Best regards,
Stu

x86 please test and mark stable.

Works nicely on my stable box. Marked x86.

it's CVE-2006-2878, and probably CVE-2006-2945 too

(In reply to comment #8)
> it's CVE-2006-2878, and probably CVE-2006-2945 too
> 

CVE-2006-2945 is another issue, B4, doesn't merit a GLSA, but it has been
corrected with the same version bump.

Thx everyone.

GLSA 200606-16

(In reply to comment #9)
> (In reply to comment #8)
> > it's CVE-2006-2878, and probably CVE-2006-2945 too
> > 
> 
> CVE-2006-2945 is another issue, B4, doesn't merit a GLSA, but it has been
> corrected with the same version bump.
> 

I have upgraded to dokuwiki-20060309-r1 but the bug stated in CVE-2006-2945 is
still present. I checked the php files, and the fix suggested by developer(*)
is in place, around line 50 of inc/actions.php, but still a user can access
restricted pages by changing their profile in access denied page.

(*) http://bugs.splitbrain.org/?do=details&id=825

> I have upgraded to dokuwiki-20060309-r1 but the bug stated in CVE-2006-2945 is
> still present. I checked the php files, and the fix suggested by developer(*)
> is in place, around line 50 of inc/actions.php, but still a user can access
> restricted pages by changing their profile in access denied page.
> 
> (*) http://bugs.splitbrain.org/?do=details&id=825
> 


mmm... this shoud be reported directly to the developer. Only him can act on
this