Re: CVE Request: Horde_Ldap: Stricter parameter check in bind() to detect empty passwords

[Matthew Daley <mattd () bugfuzz com>]

On Thu, Jun 5, 2014 at 6:01 PM, Murray McAllister <mmcallis () redhat com> wrote:
> On 06/05/2014 05:51 AM, Salvatore Bonaccorso wrote:
> > Hi,
> >
> > Horde_Ldap released an update fixing a security issue mentioned in the
> > changes:
> >
> > > [jan] SECURITY: Stricter parameter check in bind() to detect empty
> > > passwords.
> >
> >
> >
> > https://github.com/horde/horde/commit/8f719b53b0ee2d4b8a40a770430683c98fb5f2fd
> >
> > fixed in 2.0.6 with commit:
> >
> >
> > https://github.com/horde/horde/commit/4c3e18f1724ab39bfef10c189a5b52036a744d55
> >
> > Could a CVE be assigned for this issue?
> >
> > Regards,
> > Salvatore
>
> Thanks for pointing this one out. FWIW, I discussed this issue with Kurt
> Seifried and we believe it would be hardening fix, not a CVE-named issue.
>
> It seems this flaw could let you accidentally connect to an LDAP server
> without a password, but the flaw in this scenario is in the LDAP server, and
> this fix helps prevent you from doing that.
>
> Some further explanations about this are available in
> http://securitysynapse.blogspot.ca/2013/09/dangers-of-ldap-null-base-and-bind.html

Hi Murray et al.,

I originally reported this bug to Horde and - as you may guess - I
respectfully disagree with this assessment :)

The issue *sounds* like the usual unauthenticated bind issue, but
isn't; indeed the vulnerability still manifests when Horde is using
OpenLDAP (which explicitly denies such binds by default).

Horde has a simple function wrapper, Horde_Ldap::bind, around PHP's
ldap_bind function. This function takes a DN and password as
arguments, both with default values of null. If either of these
arguments is empty() (as in, the PHP standard library function
empty()), the LDAP bind user DN or password from Horde configuration
is passed to ldap_bind instead.

I'm guessing the intent is that the function can be used to easily
(re-)bind as the bind user by calling it with no arguments (making
them default to null and therefore passing the empty check).

The issue is that empty() returns true not just for null values but
also - amongst other things - for empty strings. Hence, a user can
simply provide an empty password when logging in and the function will
default it to the bind user's password. All the user then needs to
guess is the same bind user's DN (ie. username, so probably something
like 'horde' or 'admin') and they can log in.

(Note that IIRC you can't provide an empty username to get that to
default as well; Horde checks for a non-empty username but not an
non-empty password.)

So, this issue was actually Horde-specific and not a generic LDAP
server configuration issue, which I think qualifies for a CVE, FWIW.

Cheers,

- Matthew Daley