Date: Sat, 28 Jun 2014 15:15:58 +1200 From: Matthew Daley <mattd@...fuzz.com> To: oss-security@...ts.openwall.com Subject: CVE request / advisory: Cherokee Hi, I'd like to request a CVE ID for this issue. It was found in Cherokee (<http://cherokee-project.com>), an open-source webserver. This is the first such request (albeit a late one); this message serves as an advisory as well. Affected software: Cherokee Description: Cherokee supports authenticating users via LDAP. It does not ensure that users provide a non-empty password when doing so. If the underlying LDAP server allows unauthenticated binds (see RFC 4513, section 5.1.2: <http://tools.ietf.org/html/rfc4513#section-5.1.2>), an unauthenticated bind will be performed and not the name/password-based authenticated bind that Cherokee is expecting. This success of this bind will cause Cherokee to authenticate the user. This allows an attacker to authenticate as a user for which they only know the username and not the password. Affected versions: current releases (<= 1.2.103) Fix: https://github.com/cherokee/webserver/commit/fbda667221c51f0aa476a02366e0cf66cb012f88 Reported by: Matthew Daley -- I am aware that the CVE eligibility for an issue like this is sometimes questioned, and so I would like to offer my opinion: Having unauthenticated binds enabled on an LDAP server is indeed dangerous because of the possibility of security issues like this one arising. OpenLDAP denies them by default for this very reason (see section 14.3.1 of the OpenLDAP server administrators' guide, <http://www.openldap.org/doc/admin24/security.html#Authentication%20Methods>), but other servers such as Microsoft's Active Directory and Novell's eDirectory have them enabled by default. However, the fault lies with the client application that is using the LDAP server to authenticate and not with the server or its configuration itself. Providing an empty password is the RFC-specified way to perform an unauthenticated bind. It is up to clients themselves to ensure that if they want an authenticated bind performed, and not an unauthenticated one, that the password they provide is indeed non-empty. When an application is binding in order to use the resulting success/failure of the bind to decide whether to authenticate an external user, and not in order to access privileged LDAP directory information, this is always the case. RFC 4513 agrees, see section 6.3.1 (<http://tools.ietf.org/html/rfc4513#section-6.3.1>). Section 5.1.2 (<http://tools.ietf.org/html/rfc4513#section-5.1.2>) recommends that servers default to disabling unauthenticated binds as well. However, if an administrator needs or wants to enable unauthenticated binds on a server, doing so should not cause other applications' authentication routines to become vulnerable to bypass in this way. In the past, CVEs have been assigned for this issue in other applications, such as Apache Shiro (CVE-2014-0074), JBoss (CVE-2012-5629), Spring Security (CVE-2014-0097) and PacketFence (CVE-2011-4068). -- Please let me know if you need any further information. Thanks, - Matthew Daley
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.