log4j actually has something replacing an expression in curly brackets with something that can make a network call? And that just sat there?
From the look of it, it’s not just an edge case of jndi either, it seems it’s the purpose of the whole prefix?
When would a network request ever be a valid thing to do as a result of logging?
Not to mention, when would it ever be acceptable to run remote code as a result? Or was the execution of a remote class using a vulnerability and not by protocol design?
This was by design. Java has a history of these kinds of wild exploits ever since the XML days.
The original use case was probably something like: we want to be able to customise the logging on a per user/customer basis, so if we can make a call to our LDAP server, we can return a Java class that will implement that customisation.
This is definitely the kind of thing you'd get from an enterprise IT consultancy when you ask for an ERP system and require services to authenticate via ActiveDirectory.
It's easy to imagine a chain of changes, starting from innocuous string substitution with static strings in the code base and gradually building up to downright exploitable network access and multiple substitutions, all based on the previous changes as precedent (we already do substitutions, this is just one more).
That's not to say it shouldn't have been obvious, but string substitution using functions can have non-obvious impacts as functions call functions which are then modified later by someone else to do crazy things like network calls or parsing code for the sake of convenience.
You see the same in say rails templates which might fire off dozens of expensive sql queries to a database and without changing the template but just changing one of those methods on a model the entire performance profile can change - nobody is to blame exactly, but the entire system makes it easy to shoot yourself in the foot.
As far as I can tell they had some shared configuration for multiple web services exposed on jndi and wanted to refer to that in log4j directly instead of having to import it manually.
> From the look of it, it’s not just an edge case of jndi either, it seems it’s the purpose of the whole prefix?
The original purpose of JNDI, back in the "the network is the computer" days at Sun, was all about accessing remote objects without having to care about where they were located.
The current use of JNDI, however, is about accessing resources external to the current J2EE web application, but still within the same JVM instance. For instance, using the JNDI name "java:comp/env/jdbc/something" to access a database configured on the application server.
It's this last use which AFAIK was the motivation for adding that lookup to log4j: it allows adding some metadata about the current web application context to the log output. The original use of JNDI, to access remote resources, has mostly been forgotten, and could be considered a vestigial feature nowadays.
It probably went down as there is JNDI, a separate widely-used tool. Log4j wanted to add an option to log properties, like “Started logging ${app.name}”, for which they chose this approach. They just didn’t think through/didn’t know the reach of JNDI, but both things make sense separately.
From the look of it, it’s not just an edge case of jndi either, it seems it’s the purpose of the whole prefix?
When would a network request ever be a valid thing to do as a result of logging?
Not to mention, when would it ever be acceptable to run remote code as a result? Or was the execution of a remote class using a vulnerability and not by protocol design?