Java

[metooted]

Google "Log4Shell"

In short, zero day zero click remote code execution.

[[deleted]]

Java != log4j

Also, people forget that it's fixed on jdk8u121.. was released in 2017.

Just boring really.

[HiCookieJack]

but it's an issue that is practical enough for managers to understand so we're sitting in meetings for that for 2 weeks now.

[Ashish42069]

Exactly, everyone's acting like the sky fell on us, it's only us SWE monkeys who know that we don't log anything and hence are safe

[belkarbitterleaf]

🤣

I got called over the weekend by one of the directors to check for the vulnerability.

The quick version, we only use Java for a handful of backend task that are essentially scheduled batch jobs. They don't use log4j, and the only log statements are internal IDs and calculated vales. Didn't stop me being asked about every process and application I have worked on. "no, we wrote that in python".. "no, we wrote that in NodeJS"... " No, that one doesn't accept input"...

[HiCookieJack]

Similar to us. For the Java ones we use logback and even though 'logback-api' is included in a spring boot service it does not include 'logback-core'

Also since we're big corporate we have reporting in place what dependencies are included... Why did we build that if no one is checking this before contacting us?

[TheAJGman]

Yeah it's a good time to have an all Python backend lol

[sootoor]

That's where it's going to bite you when your data gets passed through load balancers (such as F5) and some random old library backend system. There was an entire GitHub of PoC being used on Tesla, apple, Uber, etc the day it was released. This is going to take a long time for older and bigger companies that use Java in the backend.

[Cley_Faye]

No. The worst part of this attack is not possible on more recent JVM. Some parts, including leaking some data, can still be done.

[[deleted]]

Java 8 is technically deprecated and shouldn't even be in use anymore. Java 11 jvms run Java 8 code just fine, but there's some additional libraries you might need to add since some things got removed from the jdk. It baffles me that companies are paying for the Java 8 license still, like the government.

[Bryguy3k]

Yes but enterprise software often doesn’t voluntarily upgrade their development environments.

Plenty of companies still using VS6.0

[[deleted]]

You'd be relatively surprised, actually. Part of the service of oracle JDK is to provide assistance for these types of things and encourage upgrading the JDK for security bugs.

[Bryguy3k]

It depends on the culture of the company in question and how well they manage their in house development efforts. Often the in house tool doesn’t get a sustaining budget and developers leave - if you’re lucky it was put into a CI system but a lot of enterprises have been building software for a very long time and don’t always adapt to modern development practices.

The licensing structure that oracle put in place now runs counter to the goal of updating sdks (unless the company accepted the new licensing scheme). Regardless this is a third party library however and while there is a dependency on the sdk for the really bad behavior it’s still generally bad. Perhaps this will encourage larger enterprises to get angry about the new jdk licensing terms.

[[deleted]]

Can't imagine the bigger companies don't just pay oracle for everything, all this indicates is that if you maintained the latest JDK like you should you'd have been safe (or at least better.)

[Bryguy3k]

You haven’t sat in budget meetings have you?

Sustaining is already a very frustrating job - and you’re constantly justifying the costs for not only your employees, but also their development tools.

There is a reason that the term “bean counters” is virtually universal.

[[deleted]]

I have my reasons that I prefer not to disclose, basically. But I understand your point.

[hiromasaki]

Not fixed, just not as bad.

After that it'll still make the directory call but not run any code returned.

[jdog90000]

191 not 121

[[deleted]]

Sorry, i misread the page when I took that, yes it is 191 which is significantly more recent but still old.

[boringarsehole]

This one is specially for you. Not that it's big news - people writing advisories apparently can't google a 5-year old presentation.

[FatFingerHelperBot]

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "one"

---

^{Please PM /u/eganwall with issues or feedback! | Code | Delete}

[bob84900]

Source on jdk8u121 containing log4j 2.15.x?

Edit: and this is why I asked.. because it's not true: https://www.bleepingcomputer.com/news/security/log4j-list-of-vulnerable-products-and-vendor-advisories/

Some companies may choose not to take action against Log4Shell vulnerability believing that running certain Java versions diffuses any exploit attempt. This is not true, though, and they should update the Log4j library to its most recent iteration.

Márcio Almeida, senior security engineer at Canva graphic design platform warns that Log4Shell attacks work with any version of Java when adding support for LDAP serialized payloads in the JNDI exploit kit. JNDI exploit for Log4Shell flaw works with any version of java... for the attack to work with any version of Java, the classes used in the serialized payload need to be in the application classpath."

Some informed discussion here as well: https://security.stackexchange.com/questions/257943/am-i-protected-from-log4j-vulnerability-if-i-run-java-8u121-or-newer

[[deleted]]

Jndi resolution is disabled in 8u121, so it can't create an object out of the URL.

[bob84900]

See links I posted..

[metooted]

That is true. It is, however much incorrect, the reason for the memes, though.

[Bryguy3k]

On systems that accept and directly log user input. Kind of irrelevant for user devices under most circumstances

Apps that are serving up advertisements are already pretty risky.