Date: Mon, 9 Jun 2014 21:03:15 +1200 From: Matthew Daley <mattd@...fuzz.com> To: Murray McAllister <mmcallis@...hat.com> Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, carnil@...ian.org Subject: Re: CVE Request: Horde_Ldap: Stricter parameter check in bind() to detect empty passwords On Thu, Jun 5, 2014 at 6:01 PM, Murray McAllister <mmcallis@...hat.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ