It has been years since I used it but I can't remember a valid reason why it should be allowed to do so.
Since it is running inside the stack it may not be easy to enforce it. If the "client" log4j does it before even logging that is a bother.
It seems like having a "central" "syslog" logging server.
Traffic goes from the stack -> logging server. Logging server not allowed to call anyone external.
The idea that a logging framework could lead to an RCE like this is completely bonkers. The vast majority of users just want to log straightforward data.
I mean seriously, who thought this was a good idea? It's about as dumb as allowing a SQL server to execute shell commands or read/write directly to files, or for XML documents to allow external entities that can fetch from URLs or local files.
Even worse is when these gaping security holes are enabled by default.
Nobody there seemed to be aware that the log message text itself is also subject to lookup syntax interpretation and that this would be dangerous given that JNDI also allows remote code-base download and execution from the specified URL.
By "nonstandard" do you mean different than default settings? It looks like they changed the default as of v2.15: https://issues.apache.org/jira/browse/LOG4J2-3198
For earlier versions (2.10+) it looks like there's a single setting you can toggle to prevent the lookup behavior:
log4j2.formatMsgNoLookups=true (or env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true)
1. Attackers can still load code in your class path.
2. Attackers can steal environment variables, VM information, system information, etc.
3. The issue isn't specific to LDAP in any way, that was just a particularly brutal way to exploit this vulnerability. There are other ways to achieve RCE.
We may find even more ways to attack this in the future. It is absolutely not a good idea to assume you're safe right now - if you have log4j in your dependency tree, you should keep a close eye on the discourse as it evolves.
edit: I'll just say that I think it's really premature to tell anyone that they're safe.
Failing that, it would be interesting to see this implemented as a linter--low level I/O and HTTP functions are annotated such that callers must have the appropriate capability annotation in order to call them. This wouldn't prevent a nefarious library publisher from making HTTP requests through an FFI or an alternate HTTP library unknown to the linter, but it would prevent attackers from exploiting bugs/misfeatures in libraries as in this log4j case.
Unfortunately both of these platforms have removed their security controls - the JVM's SecurityManager[0] was deprecated and recent versions of .NET have dropped sandboxing. [0] https://openjdk.java.net/jeps/411
What is the intended scope of log4j? I spent some time looking over the source code and cannot fathom why something that logs information would need to become this complicated.
That's easy: because software development is complicated. If you look at the ticket where this was added[1], it seems like a reasonable request for something a very featureful logging library might do. Other logging frameworks[2] already supported this feature.
It's easy to armchair quarterback and say the feature shouldn't have been added, but the reality is an old project like this that's used by many large enterprises with specific requirements is going to naturally bloat as it ages.
Anyone who's been in software dev long enough has experienced this. You build a super-simple internal tool or library that does solves a specific problem you have. It starts getting used. Then you get a feature request from Department A to do something slightly different. Department B says you need to integrate the tool with their new CRM platform. The security team gets involved and says you need to integrate auditing of your tool's usage into their metrics. etc...
For Apache/log4j, it's not just multiple departments, but a wide array of companies across the entire world. It's very easy to explain feature bloat.
I probably spend more time grepping dependencies than googling for fixes. Scope kills.
But yes, I think a major issue here is a logging library packaging its own meta language that can trigger side effects.
If it's in the application execution context, it will have the same abilities.
If your middleware needs to make calls to third-parties, and it uses log4j, the log4j code has the same rights as the middleware app.
If you're using a registry like Nexus, and it uses log4j, then it also has the ability to make calls to Maven repos, pypi repos, and anything else that Nexus can reach.
And so on and so forth.
Essentially you're expecting there to be privilege separation, where there is none.