Coordinated Disclosure Timeline
- 2021-12-16: Report sent to private@logging.apache.org
- 2021-12-17: Issue gets fixed and released as part of 2.16
Summary
The mitigations to restrict the hosts that a LDAP lookup can connect to, and the classes that can be deserialized are bypassable.
Product
log4j2
Tested Version
2.15.0
Details
Issue 1: allowedLdapHost mitigation bypass (GHSL-2021-1054)
There is a parser differential between java.net.URI and com.sun.jndi.toolkit.url.Uri. The latter does not account for # which enables an attacker to provide an URL that is processed differently by the two URI parsers. For ldap://localhost#.acme.com/a}, java.net.URI will see localhost as the URI host and will use this value to decide if it can connect to it. However, com.sun.jndi.toolkit.url.Uri does not account for #, so it will get localhost#.acme.com as the host and perform the JNDI lookup against this host.
Impact
This issue may lead to mitigation bypass
Issue 2: allowedClasses mitigation bypass (GHSL-2021-1055)
There are two possible bypasses for this control:
An attacker can provide any arbitrary name in the javaClassName LDAP attribute. By setting it to java.lang.String, the allowedClasses check will succeed and will proceed with the unsafe deserialization.
Additionally, there is a TOCTOU race between the time that the ldap attributes are retrieved and checked and the time when the actual lookup happens. The attacker can first respond with an empty list of attributes and then, during the real lookup, reply with the full attributes representing the serialized object.
Impact
This issue may lead to arbitrary code execution.
CVE
- CVE-2021-45046
Credit
These issues were discovered and reported by GHSL team member @pwntester (Alvaro Muñoz) and @atorralba (Tony Torralba).
Contact
You can contact the GHSL team at securitylab@github.com, please include a reference to GHSL-2021-1054 or GHSL-2021-1055 in any communication regarding these issues.