[dokuwiki] Re: Fwd: Dokuwiki (maybe) security issue: Null byte poisoning in LDAP authentication

  • From: Christophe Drevet <dr4ke@xxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Thu, 18 Sep 2014 22:19:18 +0200

Hi Andi,

Thank you for forwarding this message.

2014-09-18 20:10 GMT+02:00 Andreas Gohr <andi@xxxxxxxxxxxxxx>:

> Hi *,
> I recently got the message below which seems to point to a security
> flaw in relation to LDAP/AD authentications. It's a long mail and I'm
> not 100% sure I understood it correctly. But it seems there's a way to
> a) zero out a password, switching the login to an unauthenticated one
> b) zero out user and password, switching the login to an anonymous one

This is what would happen to the ldap bind itself. It's not harmful, the
LDAP is designed to allow such bind, the LDAP server would consider this as
anonymous or unauthenticated login, thus allowing not much access. So it's
not a threat to the LDAP.

However, a vulnerable application doing the bind just assumes (I'm not sure
it can be different) that a *successful* bind is always an *authenticated*
bind. To the application, the user would be allowed access *as if it was
authenticated*. It would allow anyone to login with any account without
password. That is a serious threat to the data contained in the application.

Now I know I'll have some work tomorrow, testing dozens of internal PHP
apps for this vulnerability.

> I think the correct way to fix this is removing zero bytes from the
> affected strings. I could implement that in various places and I
> wonder what would be the best:
> 1) in the LDAP and AD auth plugins
> 2) in the auth handling (thus applying to all auth plugins)
> 3) in $INPUT filtering all GET and POST vars always
> I am leaning towards 3) but there might be a reasonable case where you
> might want to post a zero byte?

I would agree. But I'm not the particularly qualified to answer that. At
least, it should be done at 2).

> I am also not sure about the severity of the bug and would like to get
> your input on that.

I didn't test it in live, I'll do that tomorrow.

But as I understand it, it's pretty serious for corporate users. However,
for dokuwiki, I guess it's less a threat than for others corporate
applications, that could be designed to work with critical data.

Thanks again for spreading this information.

By the way, it reminds me that I was reading, just yesterday, about
passwordless authentication:
I'm not sure I entirely agree with this paper but it has a point.


Other related posts: