oss-security - CVE request / advisory: Cherokee

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAD3Caney1k9wZq_6iFiDOQdHxuKtSZmO96WY77kSEsfUu_vyMg@mail.gmail.com>
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

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.