Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 16 Oct 2014 12:07:42 -0400 (EDT)
Subject: Re: CVE request: various security flaws in dokuwiki

Hash: SHA1

> The following security-related flaws have been fixed in the
> 2014-05-05 and 2014-09-29 releases of dokuwiki:


There are two CVE IDs for 765 because there are apparently two
different types of problems.

> I can simply open an image I have no permission for in the media
> manager, I get a permission denied message in the media details tab
> and when I click on the detail tabs they load via ajax with the real
> content.

This issue appears to be about incorrect authorization logic in the
inc/template.php file. Use CVE-2014-8761.

> The media diff ajax call is a bit more difficult to test as the ns
> parameter (but only that one) is a post parameter, but after changing
> the code to accept a get parameter as well I can clearly see that it
> uses the ns parameter for the permission check (and nothing else).

Here, within the ajax_mediadiff function, the ns parameter is
untrusted input, so this is an instance of CWE-807. Use CVE-2014-8762.

There was also a third report in 765:

> I noticed this same issue with media manager & acl just today, but
> from the other way around. When a user has full access to a namespace
> but no access to the parent namespace. The media manager shows the
> images but gives a denied access message when viewing details.

We think this might not be a vulnerability, if the user in this
scenario was supposed to be able to view details, and "a denied access
message" suggests that the authorization check was incorrect only
because it was too strict. There is currently no CVE ID for this.


The first issue is about a valid username, and a non-empty password
that begins with a \0 character. It is analogous to CVE-2014-8088 in
the post and
CVE-2014-6387 in the post. Use
CVE-2014-8763 for the occurrence of this mistake within DokuWiki.

> In addition, I have just found that Dokuwiki is also vulnerable to
> null-byte-forced anonymous binds (as opposed to just unauthenticated
> binds):
> With a Dokuwiki instance using Active Directory for LDAP
> authentication (as described earlier), one can log in using a username
> that has a null byte as the first character and with a password that
> similarly has a null byte as the first character. This will result in
> an anonymous bind being performed by Dokuwiki, and hence the log in
> will always succeed, regardless of the whether the username exists or
> not in the LDAP directory.

Use CVE-2014-8764 for this additional issue. (Within an application
that uses LDAP, input validation related to the possibility of an
empty or invalid username, and input validation related to the
possibility of an empty or invalid password, are relevant for
different reasons.)

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.