Hi Gary,

Thanks for the offer! I take the credits as suggested.

Kind Regards,
Gregor

On 27 Jan 2021, at 10:45, Gary Tully wrote:

HI Gregor,
I am going to file a CVE for this issue.

CVE-2021-26117

would you like a credit?

Credit:
This issue was discovered by:

* Gregor Tudan - <gregor.tu...@cofinpro.de>

see example: https://stack01.cloud.nospamproxy.com/link?id=BAgAAAD_YBHdTJqTjq0AAADSrn_t-5d3Z8OyHrdNw5EhsqJh18TEXTL43w_OqAtD6I4jZ8cVY5AhJ-w-2z5kwMnSKN0HfEbjtlx-vik6XNEQqU7RhCS_ehZN_4NqpysvLtN8oTysUklDnUHfecnEXWjdZFM1MmeyMCm6ye2gnCrBDO4o2Rtgzk7xXCc9xRBu8FGV_b1v8HnS7fp1ePa_J091ruSJtJjv4YWNVISfzlpZxXKSLRpW0kb6lZ1HQw2

It can be omitted or just your email or more information if you wish,
it is up to you.

kind regards,
Gary.


On Mon, 7 Sept 2020 at 17:32, Gregor Tudan <gregor.tu...@cofinpro.de> wrote:

Hi Gary,

Thank you for the quick fix, I wasn’t expecting such a fast response! But are you sure you want to put this in public JIRA already?

I know several installations that use this kind of setup and none of my contacts there were aware of this limitation. Putting this into public without a fix/release in place will jeopardize those deployments.

For the fix: looks good to me!
Some beautification: it would be cool if we could allow the connection-username/password to be left unset if the authentication-method is none. It’s kind of unintuitive having to configure anonymous bind and still requiring some (random) connection credentials.

Thanks again!
Gregor


On 7 Sep 2020, at 17:44, Gary Tully wrote:

Thanks Gregor,
that is a lovely informative bug report.
I have opened https://stack01.cloud.nospamproxy.com/link?id=BAgAAAD_YBHdTJqTjowAAABvI9-ioeBrRR5owA7oY_c9pTFK7stcJA7KisgdOUHeP-Y5MHRyHbZninJNAMM4Pkn5h95kcEkkFH4jzaem1bxizucd5EjOaHPgPNg8RkCeky1ig9QshjWWSiZPPv5_HGWH2CvM-LEf6pnC67AZl-bamdD04fYcHXf7VTDGqxP5whY1U9LTFvJOuHv2cQ2 to track the fix for this issue.
It would be great if you could cast your eyes over the test and fix.

https://stack01.cloud.nospamproxy.com/link?id=BAgAAAD_YBHdTJqTjp4AAACFIxa1OKE5YBtt86sUOceH2rhNzN7d0BVQu6FFmvasoC3eJ0OL2ZvbsY9wc0-8p5LdWZ3YEBEDJu1zWCo-OXXBGnQgI7_eAm9YMOSTozr71xOh0BMx0F2_Ut1SMV73iNsC2OBGpMdrv0QbpvNLTd3GOBl611nPX9wC8XAh7uwqgXdjRBsxILusYQaPZeRs_R3HTcYXSjAAjeRPKiw4bA2

I think the same problem exists in 5.x, I will verify that next.

kind regards,
gary.


On Mon, 7 Sep 2020 at 13:40, Apache Security Team <secur...@apache.org> wrote:

---------- Forwarded message ---------
From: Gregor Tudan <gregor.tu...@cofinpro.de>
Date: Mon, Sep 7, 2020 at 11:10 AM
Subject: Artemis: LDAP-Authentication does not verify passwords on
servers with anonymous bind
To: <secur...@apache.org>


Hi,

I’d like to report a security related bug in the latest version of
ActiveMQ Artemis:
The LDAPLoginModule does not verify user credentials on servers that
use anonymous bind.
A user can login with any password, as long as the user exists in the directory.

I’m referring this chapter in the documentation:
https://stack01.cloud.nospamproxy.com/link?id=BAgAAAD_YBHdTJqTjrsAAAA2jeLO6uKoKpMHfKb7DNX2rEsgw7GUl_8jSh9p1im_xEMLIQhtqd3zlcYGPOVqIqur6EupnNfCIvZ8YWxdWhuHF_PXC3PAEOIktKgiSz46C2GE4TS5daHejGyC2sCbFzxRUl4_RcWpw67u3TAlBhutxr6Hr5aAw4uCUTT_ankDbXUBKyiUNGTJyZRM4FckKKHOaF_dScCjIKfQqt0XPHlQSZmHjE3fTgOECrO5vEntM_myXqHgzglKMxbV0

We use the LDAPLoginModule with an LDAP server that uses anonymous
bind (no connection-user or password).
Here’s the login configuration:

org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule sufficient
       debug=true
       initialContextFactory="com.sun.jndi.ldap.LdapCtxFactory"
       connectionURL="ldaps://ldap.tech.visualvest.de:636"
       authentication="none"
       authenticateUser=true
       connectionProtocol=""
       connectionUsername="none"
       connectionPassword="none"
       userBase="ou=people,dc=visualvest,dc=de"
       userSearchMatching="(uid={0})"
       userSearchSubtree=false
       roleBase="ou=groups,dc=visualvest,dc=de"
       roleName="cn"
       roleSearchMatching="(member={0})";

The AuthenticateUser-Property is set to true, so the credentials
passed to the module should be verified.
The common pattern for this is:

the service connects anonymously to the server
it looks up the user and its roles
if the user exists, it connects to the server using the provided
credentials. If this is successful, the user may proceed.

This scheme is quiet common and supported by pretty much any software
with LDAP-Authentication support.

In the logs, everything looks like I’d expect it:

2020-09-07 10:01:59,016 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Create the LDAP initial context.
2020-09-07 10:01:59,017 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Referral handling: ignore
2020-09-07 10:01:59,067 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Get the user DN.
2020-09-07 10:01:59,067 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Looking for the user in LDAP with
2020-09-07 10:01:59,067 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
base DN: ou=people,dc=mydomain,dc=de
2020-09-07 10:01:59,067 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
filter: (uid=gtudan)
2020-09-07 10:01:59,072 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
LDAP returned a relative name: uid=gtudan
2020-09-07 10:01:59,072 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Using DN [uid=gtudan,ou=people,dc=mydomain,dc=de] for binding.
2020-09-07 10:01:59,072 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Binding the user.
2020-09-07 10:01:59,079 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
User uid=gtudan,ou=people,dc=mydomain,dc=de successfully bound.
2020-09-07 10:01:59,079 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Get user roles.
2020-09-07 10:01:59,079 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Looking for the user roles in LDAP with
2020-09-07 10:01:59,079 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
base DN: ou=groups,dc= mydomain,dc=de
2020-09-07 10:01:59,079 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
filter: (member=uid=gtudan,ou=people,dc=mydomain,dc=de)
2020-09-07 10:01:59,086 DEBUG
[org.apache.activemq.artemis.spi.core.security.jaas.LDAPLoginModule]
Roles [entwickler] for user gtudan

The problem is that during the bind, the authentication-method is not set (https://github.com/apache/activemq-artemis/blob/77bbf49a4f1a5c399313e3246b1fd18f5e8a3b54/artemis-server/src/main/java/org/apache/activemq/artemis/spi/core/security/jaas/LDAPLoginModule.java#L590).

On servers that require simpleAuthentication the context will have the authentication method preconfigured in the context and authentication
will work as expected.
On servers with anonymous bind, the authentication method has to be
added to the environment before the bind
(ctx.addToEnvironment(Context.SECURITY_AUTHENTICATION, "simple“);).
Otherwise the provided credentials will be ignored. The following
lookup succeeds, since it keeps using the anonymous context.

I’m happy to provide any additional information that you might require.

Regards,
Gregor Tudan

Reply via email to