Skip to main content

Hardened LDAP call against deserialization attacks


ImportanceReview GuidanceRequires Scanning Tool
HIGHMerge After Cursory ReviewNo

This change patches the LDAP interaction code to harden against a remote code execution vulnerability.

Using Java's deserialization APIs on untrusted data is dangerous because side effects from a type's reconstitution logic can be chained together to execute arbitrary code. This very serious and very common bug class has resulted in some high profile vulnerabilities, including the log4shell vulnerability that rocked the development and security world (and is still present in organizations, by the way.)

Now, back to the change. The DirContext#search(SearchControls) API is used to send LDAP queries. If the SearchControls has the retobj set to true, the API will try to deserialize a piece of the response from the LDAP server with Java's deserialization API. This means that if the LDAP server could influenced to return malicious data (or is outright controlled by an attacker) then they could execute arbitrary on the API client's JVM.

Our changes look like this:

  DirContext ctx = new InitialDirContext();
- var results ="query", "filter", new SearchControls(0, 0, 0, null, true, false));
+ var results ="query", "filter", new SearchControls(0, 0, 0, null, false, false));


Why is this codemod marked as Merge After Cursory Review?

The protection works by denying deserialization during processing of an LDAP query which we're confident is intentional in a vanishingly small percentage of usage.