jyemin opened a new pull request #618:
URL: https://github.com/apache/logging-log4j2/pull/618
Check that the class name in the `javaClassName` attribute exactly matches
the class name in the `javaSerializedData`
attribute.
Background:
The new documentation states the following:
> When using LDAP only references to the local host name or ip address are
supported along with any hosts or ip addresses listed in the
log4j2.allowedLdapHosts property.
This seems to be the primary line of defense against CVE-2021-44228
(Log4Shell). However, the second line of defense goes further:
> Only the Java primitive classes are supported by default as well as any
classes specified by the log4j2.allowedLdapClasses property.
Unfortunately, this guarantee seems easily subverted.
Suppose that an attacker in control of an LDAP server returns a set of
attributes like this:
```
javaClassName: "java.lang.String"
javaSerializedData: <serialized data for some attackable class, not actually
java.lang.String!>
```
In this scenario, Log4J's `JndiManager#lookup(java.lang.String)` will
determine that the object is safe to deserialize based on the value of the
`javaClassName` attribute (because `java.lang.String` is on the default allow
list), and then proceed to call
`javax.naming.Context#lookup(java.lang.String)`, which will deserialize the
data in `javaSerializedData`. One might think that the JDK's LDAP
implementation for JNDI would first check that the object in
`javaSerializedData` actually matches `javaClassName` before proceeding with
deserialization, but that's not the case. It seems that it will happily
deserialize and return whatever is in `javaSerializedData`, regardless of
whether the actual class matches `javaClassName`. This is problematic, and in
my opinion a security issue with the JDK.
This patch is an attempt to mitigate the issue. It has a number of problems:
1. The attack scenario is untested. I'm unsure how to recreate the scenario
given the capabilities of `embedded-ldap-junit`.
2. It violates the strict definition of `javaClassName` in RFC 2713 (see
inline comment).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
