Log4J CVE-2021-44228

Yeah, that’s why I linked to v2.16.0

2 Likes

Would be nice to know which commonly used applications that might be vulnerable for this.
I don’t really run many applications, but still.

But why wouldn’t you just auto upgrade everything all the time by default?

2 Likes

Well i pretty much only just use one application besides the webrowser.
And i cannot really find if that app is vulnerable for it or not.
Of course the said application is up to date.
Still i’m trying to learn and figure out more about this vulnerability.

But of course i understand that this is not really relevant for this topic.
So i will ask this else where.

Still thanks for the heads up! :slight_smile:

Everytime someone chooses Java to write a piece of software God kills a kitten.

Stop using Java: Stop killing kittens.

should read:
Everytime someone chooses Java, Oracle sacrifices a kitten to it’s daemonic overlord…

Serious tho, bugs are part and parcel. It’s the app makers that should really maintain. And at least this one we know about, some are closed source, and only ATP’s / TLA’s know about them

1 Like

You mean Oracle returns cat to its true home?

Wrong. They sue the cat for violating the license agreement.

4 Likes

I feel bad for whoever has to figure out how to send takedown notices to a cat.

2 Likes

@MisteryAngel

… but, the library is so wide spread that you can plainly assume that if there’s Java, it’s affected.

… and if not on the list or not using Java it doesn’t mean it doesn’t have other issues.

Among the affected are apple icloud servers (name you iPhone “${jndi…” and get a shell iiuc), Mars quadricopter, Tesla cars.

My comment about updating was meant as a genuine question… in general the ideal is there should be no harm in upgrading, whereas staying with the old version is not something that’s generally supported by any developers of anything by default.
Even LTS branches of stuff have patch sets, but once a new patchset is released it’s done for. e.g. linux kernels have a 4 month support window. For example, 5.14 is EOL… and only support you might get is from your kernel vendor e.g. distro maybe. If a distro is on 5.12, whatever patches happen at the moment, may not make it anywhere else 5.12 is used.

With this particular issue, Unifi Controller (a piece of software using Java) is kind of notorious for introducing very annoying regressions, and many folks are hesitant to upgrade on day 1, and so they either never setup auto upgrades, or turn off unattended upgrades on their controller and only ever upgrade manually once a version is widely deployed and there’s enough feedback.

Other software that’s not upgraded may have other issues with upgrading, and/or other serious security bugs that might be overshadowed by this CVE.

In general, you should just enable automated unattended upgrades if you can… (whilst making sure you have reliable backups).

1 Like

at least this problem Can be fixed with a software update. more shell shok than spectre

This really is the gift that keeps on giving :upside_down_face:

1 Like

Just grep for your software. and cry

I have been. We’ve been searching for anything that might use the jms class for version 1.x of log4j as well. If it uses the jndi it can be used in the same way.

By default though this looks to be more rare.

1 Like

yeah, that’s the silly part.

JNDI + user input is an automatic route to RCE.

hurdur, let’s execute user input

Who thought that was a good idea?

Error: null pointer exception.

Godammit, I’ll just enable this little hack to get this PR done this Sprint in time for the release and fix it during the next hotpush

Does that ring any bells?

2 Likes

That’s exactly why I spent an hour debugging ansible with @oO.o today.

1 Like

https://logging.apache.org/log4j/2.x/

2.16 is apparently vulnerable to another exploit. My guess is 2.17 will be too.

How about, well… This:

1 Like

untitled

2 Likes