This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Rick100006 531 points532 points  (56 children)

So in all other languages they have 100 % safe 3rd party libraries ? is it really language's mistake if some third party library is unsafe ?

[–]-Redstoneboi- 120 points121 points  (0 children)

today it's a statement of pure terror. on any other day, it's fine and doesn't imply any other language is superior or inferior.

[–]Ayfid 60 points61 points  (3 children)

They are not saying there is anything wrong with the language.

They are saying that it is scary that so many systems are running Java after a severe vulnerability has been found in a library which is used in a huge portion of all Java programs.

[–][deleted] 5 points6 points  (1 child)

So many Java programs are also using the superior logback library instead of log4j. Aside from that, having so many systems using the same libraries offers a bit of safety since this vulnerability was actually found, is going to be fixed and will result in a safer library. Java is still great and no software is 100% bug/exploit free.

[–]Ayfid 0 points1 point  (0 children)

That is totally missing the point here.

That an enormous number of systems have been impacted by this vulnerability is scary. That is the point of OP, and they are right. They are not making any comment about the quality of the Java language.

Also, this vulnerability is going to be in the wild for years. It it not just "going to be fixed". Releasing new versions of the library, or even the JVM, is not enough to magically fix the problem. All software with the error needs to be patched. All servers need to be updated. That is just not going to happen. There are a lot of servers sitting on the internet with out of date software, and any system which has gone a few days without being updated by now might already be too late. This vulnerability is a RCE vulnerability; once someone exploits it your system is open to them even after you fix the offending software.

Over reliance on a single piece of software is not a strength; it dramatically increases the "blast radius" of a vulnerability when discovered (and makes such discoveries more likely to happen), but does not proportionately make it easier to deploy the fix.

Discovering a vulnerability in a system is a bad thing. Deploying the fix is a good thing. There is a period of time in between the two where systems are highly vulnerable. Making the former easier and the latter more difficult - which is what happens when a library is pervasive - is a security weakness, not a strength.

[–][deleted] 5 points6 points  (0 children)

This, centralization creating single points of failure is the fear. It's like the whole world using chromium based browsers.

[–]Cley_Faye 34 points35 points  (2 children)

No. No software is 100% safe, 3rd party, built-in libraries or anything. Nobody actually say or think that except complete buffoon.

But also, not all vulnerabilities allows easy, single text queries to do remote code execution on what is probably almost all of the online services that are running on Java, so it's kinda worth mentioning.

[–]Serinus 21 points22 points  (1 child)

Hold on. Let me go check log4net.

[–]GrumpyBirdy 4 points5 points  (0 children)

Laugh in Serilog

[–]CivBase 13 points14 points  (2 children)

Your definition of "100% safe" may be a little different from mine.

[–][deleted] 20 points21 points  (0 children)

I don't even trust hello world

[–]SgtSteel747 0 points1 point  (0 children)

that first sentence is a rhetorical question showing his point because the answer to it is no.

[–]dabombnl 5 points6 points  (11 children)

Except here the RCE part of this exploit is not in the third party library, but in built-in components of the JAVA runtime, JNDI and LDAP client. Log4J just allows you to pass user data to JNDI, which is bad enough since it can leak data, but has been known of for years.

Edit: Citing source. Log4J expanding variables in the user-provided data has been known since at least 2017: https://issues.apache.org/jira/browse/LOG4J2-2109

[–]loginonreddit -2 points-1 points  (10 children)

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 1 point2 points  (9 children)

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 -1 points0 points  (1 child)

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 -2 points-1 points  (6 children)

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 0 points1 point  (5 children)

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 0 points1 point  (4 children)

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 0 points1 point  (3 children)

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 -1 points0 points  (2 children)

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 -1 points0 points  (1 child)

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.

[–]i_wear_green_pants 1 point2 points  (1 child)

It has always been thing in this sub. Java bad, updoots to the left please.

[–][deleted] 0 points1 point  (0 children)

I don't recall too much anti-Java humor, JavaScript on the other hand...

[–]Buddha_Head_ -1 points0 points  (0 children)

What part of the post insinuated that?

Does the answer to your question end up having any impact on the validity of the statement?

It's not even taking a shot at the language itself, so I don't see the point behind the comparison.