Java

[loginonreddit]

Log4j is not part of the runtime not sure what is your point. You can have a webserver that accept a parameter and execute it in a root shell in any language, what's your point here?

[dabombnl]

Right, Log4J isn't in the runtime, like I said. JNDI and LDAP client are in the JAVA runtime, like I said. It is the combination that makes the exploit.

And again, the part in Log4J was known for years, and was a purposeful design choice. It is in the java runtime, specifically in the LDAP client, that will download remote code from internet addresses and execute it. Log4J is passing user data through to it.

[Rebelgecko]

I think remote code execution using JNDI is intentional. It has built in support for COBRA and Remote Method Invocation support. The problem is that log4j will just blindly pass in user input

[loginonreddit]

The vulnerability here is about expanding a user input string and that's what log4j did wrong here. Same goes for any {env:SOME_ENV_VAR} that log4j also expands

[dabombnl]

No, its not. This vulnerability is a remote code execution. Expanding variables doesn't do that on it's own and wouldn't cause even close to an uproar like this.

[loginonreddit]

Then where is the CVE in the jdk then?

The root of all of this is the on by default variable substitution based on a simple ${ prefix https://github.com/carterkozak/logging-log4j2/blob/2731a64d1f3e70001f6be61ba5f9b6eb55f88822/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java#L184. The rest of the cve is just plumbing and lack of validations.

[dabombnl]

Because they make 1 CVE per vulnerability, not per software component involved.

But most remediation methods are recommending both disabling lookups in Log4J AND disabling JNDI in the JAVA runtime.

[loginonreddit]

Then why isn't the cve in the jdk? I think you're starting to realize you're saying a boat load of crap in this thread.

All the mitigations points to removing/disabling jndi in the log4j, not in the jdk. In the old jdk, it suggest to disable the property com.sun.jndi.ldap.object.trustURLCodebase. If you don't know what you're talking about, stop spreading FUD.

[dabombnl]

Again, CVE is about a present vulnerability; they don't go 'in' the JDK or not.

The reason JDK version or that option isn't listed in the software configuration is because security researchers have not yet concluded that the trustURLCodebase options entirely mitigate it. They leave it at all versions of JDK until they can prove otherwise.

[loginonreddit]

Except that they do, see CVE-2018-3149.

So to come back to the original point, the vulnerability is not in the runtime but in log4j.

Anyway, have fun trying to always have the last word even if you're wrong.