Log4Shell (CVE-2021-44228) Updates

Does that include any fixes that at least attempt to address the immediate threat? Or is there more to come....? All good if there is more to come, just want to know if we should be looking out for more updates and responding...

2 Likes

Yes, this version has log4j v2.15.0 that fixes the vulnerability.

8 Likes

@gopher.ny Do you think you could put that in the release notes? Or somehow indicate that this is an important security update? Your post here is the only information I can find that this version patches the log4j bug.

Ideally something human-readable like "This update includes a fix for the critical "Log4Shell" security vulnerability".

2.15 also has issues, 2.16 is now the preferred version.

https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

1 Like

I'm not against getting the hub on a newer log4j version, but is it really an important security update if it can't actually do anything malicious on the hub's environment? See below. If you can't do the RCE part, it isn't that big of a deal, really.

I've spent the past 4 days having this discussion in my company. Updating is certainly the best/easiest, but just because a system has an affected log4j version doesn't mean it is automatically at high risk. You can only evaluate the true risk to any environment by seeing what can be done past the log4j issue as it's just the entry point.

All that said... Just get to log4j 2.16.0 and be done with it. :slight_smile:

1 Like

I agree that the big deal is the RCE part. But the advice I saw this morning from our security team was that the vulnerability is now exploitable on all JVM versions. There are a lot of eyes now looking very closely at how to exploit jndi in log4j, and not all of them are friendly, so the state of the art as far as what conditions can be exploited for what access and how seem to be constantly shifting. I'm glad they just made jndi opt-in only in log4j 2.16.

Indeed. Small projects like Hubitat have a big agility advantage over lumbering enterprise software, written by hundreds or thousands of people who have since left the company, with undocumented features nobody understands, etc. You can just release a new version with a simple library update, and it's not a big deal (at least not compared to a huge enterprise app).

I've spent the past 4 days taking a very close look at everything that runs on java in my company,
and concluding that everything either uses logback, or is so old it's still on log4j 1.x, so we have been spared having to decide what/how urgently to update. We were also already running on JRE versions newer than the recommended minimums for mitigation.

1 Like

Holy moley.... I can't tell you how many unique apps/installations we've looked at in the past 4 days (think hundreds, not dozens). Real mess, although the overwhelming majority were unaffected/on older versions/etc.

It is, but that doesn't mean the jvm is setup in a way that allows it to do much. That is where the details on how the java side is setup is so important.

That said, that's a really technical detail, and it is hard to analyze the guts of every java implementation.

So the easiest path is patching log4j.

Few large companies are that lucky. So as always, they will do (hopefully already did... :wink: ) internet facing 1st, high criticality internal second, and those systems with alternate mitigations or low impact 3rd.

3 Likes

As the head of Major Incident Management for the mid-size SaaS company I work for, I've been putting in ~15 hours days since last Friday. :tired_face:

This got shared around our SRE/Engineering teams on Monday and I could not agree more!

5 Likes

Keep in mind the older versions of log4j have their own security vulnerabilities and since they are obsolete and unsupported, they will not be patched . Since I don't run any java on my own servers, I don't pay much attention to them, but when the POC was released on the 2.x versions, I reviewed logs and can see a wide variety of payloads attempting to exploit various bugs as early as January of this year.

The easy mitigation is just to delete the JDNILookup.class file and then the vulnerability cant be exploited.

2.3.0.120 (just released) has the latest log4j, among other things. Grab it!

10 Likes

Nice work!

5 Likes

I don't think you understand the risk. Whatever app has the log4j library installed can be instructed to execute ANYTHING.

Say your front-ends aren't vulnerable. But they write out the log messages, your Datadog agent reads them, and viola you're running bitcoin miner software (if you are very lucky it's only that)

Say you don't use Datadog, but your archive your logs. Then you run a batch processor in the background to summarize your logs. And it's vulnerable.. voila, same problem. This little threat can find its way deep into your enterprise stack. It's a hand grenade, just waiting for any unclean hands to touch it.

...and...

You mean log4j 1.x which is 7 years end of life, and has a dozen or more known ways to get RCE which are built into every newbie wanna-be crack kit? That's worse than having the current vulnerability.

Please for god's sake I hope neither of you are decision makers at these firms. If you feel safe because you're using a 7-year EOL library with dozens of known RCE vulnerabilities :scream:

Log4j 2.17.0 has been out for 30 hours... unless Hubitat took an extra step of removing JndiLookup.class from the library, they are vulnerable to one-packet d-o-s total shutdown of the node.

1 Like

For anyone who needs it spelled out, this is how F’d up this is:

(Read the whole thread)

1 Like

There wasn't a single drop of emotion other than fear for whoever listens to them.

It is absolutely called for, given the nature of the problems they are exposed on. If I wasn't so busy, I'd dig up who they work for and find their security contacts (it's a small world) and let them know what was being said here.

With this you show that you have no idea how your hub works, how your wifi works, and just how many people have published how they access their hubitat on stackoverflow. It would only be safe if disconnected entirely, and you clearly haven't tried that because you'd learn it doesn't operate.

The only thing unacceptable here is your continued attacks on me. I spoke about the topic. Your statements are personal attacks against me, and claim expertise that you don't appear to have experience with. You continue bashing of people who do understand, witness, and are involved in cleanups of massive exploits because of people who have the same unrealistic beliefs as you.

I'll give you a hint. Plug your hubitat into a hub where you can monitor every packet. You might learn something. There's 12 things that can happen when the hub boots where malware could be inserted, and nobody has to be anywhere near it. This isn't about individuals or personal attacks. Nobody has to target you specifically. You apparently have no idea the scale and blast radius the crypto miners operate at.

I did both. I raised my concerns politely and I have long since stopped using Hubitat. Unfortunately I have friends who still have them, so I went to see how vulnerable they are. I'm glad that 2.16 was rolled out quickly -- but it has numerous issues as well, and the baseless claim that the Hubitat Java interpret doesn't load remote code is seriously offputting. Groovy itself is remote loaded code for god's sake.

I was polite about every point and more importantly I was focused on the topic.

In contrast, you were accusing, insulting, and disrespectful. You haven't contributed to the conversation, you've only attacked me.

Honestly, I'm curious. Posting in a public forum about explicit weaknesses in your employer's security isn't frowned upon where you work?

Why was this query reported for being against the rules? You attacked me for saying I should do the legally responsible thing to do. I can assure you that I'm at considerably more legal risk for knowing about a vulnerability and doing nothing than I am for saying I should report it :smiley:

This post was never in violation of the rules of this forum.

Every thing I post no matter how rational is getting hidden so all I'm going to say here is that this statement was provably false. Arguably the code in question made it an option to do something with the reply or not, but not in all cases (there will be upcoming announcements about this) and attacks where the damage was done in the query are still possible as has been shown - which led to 2.17 coming out so quick.

Honestly, just remove JndiLookup.class from the library. We've seen no breakage from this action, and not having the class at all seems to be the wisest choice.

2 Likes

This topic received too many flags and has been closed. Thanks all for your feedback. We understand this is a sensitive topic to some, if anyone has any concerns, please don't hesitate to reach out to support@hubitat.com.