LOG4J2 allows for multiple keyword types of keyword expansions in the logs. Keyword expansion is a "great way" to log items possibly only known at run time. And with trace, debug level logging - Comparing those expanded values to logged values makes debugging "easier". (The closest you'll get to breakpoints in production)
The downside (exploit) is when the expansion (lookup) does things a little too powerfully. Then other folks come along and use that to *chain* other exploits. Remote LDAP calls were not in mind when the original idea was presenting a value from "java:comp/env". That's gap #1. Then gap #2 was the ability for jndi calls via LDAP to allow serialized results to come back. And the deserialization allowed for arbitrary code execution. WIth a modern java, the (trivial) de-serialization exploit won't happen. But there are many other chaining opportunities still out there. A key takeaway is you might judge individual single exploits not to be bad. But if you can easily chain multiple ones together, then the black hat party can begin. -Tim On Mon, Dec 13, 2021 at 7:24 PM James H. H. Lampert <jam...@touchtonecorp.com.invalid> wrote: > > I can *barely* wrap my mind around the idea of getting executable code > from an RMI server, but what legitimate purpose could be served by > allowing a *logger* to resolve executable code? > >
