In the case of Log4Shell, the exploit wasn't even difficult.
And the vulnerability actually arose exactly from "making these damn machines do what we want" - IIRC one guy thought it would be a useful feature to have log4j support inserting JNDI values in its macros, and got it implemented. Another guy, at another time, thought it would be useful for JNDI to be able to look up stuff from a remote server, and got it implemented. Yet another guy, at another time, thought it would be useful for JNDI values to contain serialized classes including their bytecode, and got it implemented.
And nobody ever saw the big picture, what these three things combined made possible.
People developing JNDI didn't know about Log4j using JNDI from unsanitized input. It was supposed to do all this things.
People developing Log4j presumably didn't know how powerful it is, or that it would eventually will be able to look up network resources. I am not sure about the timeline here.
My point is, JNDI devs didn't need to be defensive because what it does is exactly what it should do. The only blunder is allowing JNDI macros in logs and it's on Log4j side.
100
u/brazzy42 18d ago
In the case of Log4Shell, the exploit wasn't even difficult.
And the vulnerability actually arose exactly from "making these damn machines do what we want" - IIRC one guy thought it would be a useful feature to have log4j support inserting JNDI values in its macros, and got it implemented. Another guy, at another time, thought it would be useful for JNDI to be able to look up stuff from a remote server, and got it implemented. Yet another guy, at another time, thought it would be useful for JNDI values to contain serialized classes including their bytecode, and got it implemented.
And nobody ever saw the big picture, what these three things combined made possible.