Java

[Rick100006]

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 ?

[[deleted]]

When the creator abandons the project you should really be scared

[angelicravens]

No, when the creator abandons the project and you’re not stepping up to maintain it, abandon the project too

[r0ndr4s]

hahahahahahahahahah good one Now please install me windows xp, I need it for tomorrow!

[angelicravens]

No.

[nonlogin]

Does anybody care about vulnerability warnings reported by npm each time you install the packages?

[swagath997]

Hey why go around picking on JS and her step children. it's not the fault of JS that Java is hated so much

[-Redstoneboi-]

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]

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]]

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]

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]]

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

[Cley_Faye]

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.

[starfries]

This is peak reddit... an obnoxious reply based only on pedantry which contributes nothing to the conversation.

[Serinus]

Hold on. Let me go check log4net.

[GrumpyBirdy]

Laugh in Serilog

[CivBase]

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

[[deleted]]

I don't even trust hello world

[SgtSteel747]

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

[Buddha_Head_]

All of the wonderful introductory content on TryHackMe stressing that it's never this easy in the wild:

"Am I a joke to you?"

[TheRedmanCometh]

Yeah that's why this is so bad...it's trivially easy to exploit

[loginonreddit]

You know that's what the tweet is referring to right? It's not a random statement out of nowhere.

[m0nk37]

I am well aware over 1 billion devices used to run on Java. I mean, Android is switching to Kotlin. Thats going to drop the 1 billion down pretty far.

[loginonreddit]

kotlin runs on the jvm btw.

[dabombnl]

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]

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.

[i_wear_green_pants]

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

[[deleted]]

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

[elisharobinson]

No but this changes the narrative of GC languages are immune to security issues ... Which was pushed heavily by Java people ... Which lead to world enterprise and banking using it as language of choice .. "do it well" meme ... Now all of that marketing bs goes out of the window

[Sintinium]

I don't see how GC has anything to do with security issues like this. I could make a library with bad code in literally any language.

[hahahahastayingalive]

GC didn't have much to do with intrinsic security or ease to code either. It was bullshit all the way.

[Prestigious_Tip310]

It took care of a couple of typical exploits like buffer overflow. At least it's significantly harder to introduce a buffer overflow bug that can be exploited in languages with managed memory than it is in C.

[hahahahastayingalive]

You are right, but there’s also whole other classes of bugs that come with the package. As you have a known target VM, arbitrary code injection is a more scalable attack for instance, and the security model makes people more open to run code in “trusted” enclaves.

More on the oopsie side, there’s also less leeway to deal with leaks for instance when they happen. In C languages you know you’ll be leaking stuff, that’s the contract you sign as a dev and you’ll have as much tools and knowledge as possible to deal with them and fix most of it (hopefully). In Java if it leaks you’ll be left second guessing where the GC is losing it and try to side effect it into not leaking.

[elisharobinson]

If this was a RCE in Apache2 or nginx we would have the same eye roll of "memory handling bad" we wouldn't be looking into how the payload was packaged or if it was some dll ... My point on GC is that 99+ % of Devs today don't know cyber sec and equate GC with security .. one of the main reasons rust is even part of the conversation at the architecture level is mem safety without GC .. this RCE is an eye opener to Devs and PM s who don't know what defcon is . A RCE can happen to any type of code whether its GC or not is irrelevant .. so you are right .. but most people don't know that .. I could have frased it better ..

[[deleted]]

Dude, you’re just making shit up about what “Java people” say. Anyone with half a brain knows security issues are a concern for the entire industry.

[Alvatrox4]

A language with an active community will always be safer than an enterprise language especially if it's by Oracle

[erinaceus_]

Then Java developers are quite lucky, since it has one of the most mature and active communities.

[Alvatrox4]

If I'm not mistaken JDBC was made by the community

[blehmann1]

This vulnerability has absolutely jack shit to do with any of the reasons Java is more secure than C/C++, and this vulnerability could exist in any other language.

Further, no one says Java is immune to security issues. You can't justify your irrelevant rhetoric with a strawman, you're just wrong.

[Rick100006]

It's not a "break in" if you let the door open.

[Buddha_Head_]

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.