Log4j vulnerabilities and updates

This is somewhat related to the overall update post, but since there are now multiple concrete vulnerabilities that affect HestiaPi, I think it deserves its own thread. Jump to the bottom of this post if you just want the mitigation for a HestiaPi.

The Facts

Two vulnerabilities were found in log4j (CISA advisory, Wired article on the impact, VentureBeat article showing how ransomware operators are using this vulnerability).

This did affect OpenHAB (discussion on their forum, Official OpenHAB Security Advisory). There is no patch for OpenHAB 2, only the OpenHAB 3 branch.

How HestiaPi is affected

The default configuration for HestiaPi is that there is no authentication in order to interact with the system. As such, I expect it is exploitable by any attacker on HestiPi users’ LANs.


I believe the mitigation that Kai describes on the OpenHAB forum (which can be manually applied to any OpenHAB installation) addresses CVE-2021-44228, but not CVE-2021-45046. This seems like a bare minimum since the former is command injection, while the latter is merely a Denial of Service (DoS). While I don’t like the idea of someone disabling my HestiaPi, at least that’s something I can detect (too hot/cold) and respond to. Hopefully there will be a future update that updates to Log4j 2.16.0 to actually fix the vulnerability, but that should be addressed by moving to OpenHAB 3 and doing the aforementioned general Buster (or later) refresh.

I’ll leave the discussion of the refresh in the other thread, but it would be nice to produce an updated image with this fix if we can. I’m still working on an automated build process. I’m currently having problems where the CI environment is different than my local environment, but I’m sure I’ll get it sorted out sooner or later. Point being: don’t wait for me because I’m not sure how long this will take to get resolved.

Quick Mitigation Instructions

To Mitigate your HestiaPi, SSH in as the pi user, and follow the instructions below. These will work in the default configuration (if you have modified /etc/default/openhab2, you may need to edit that file manually).

First, we’ll check to see that the vulnerability is not mitigated.

/usr/share/openhab2/runtime/bin/client -p habopen "system:property log4j2.formatMsgNoLookups"

We expect this to say “null”, which means the mitigation is not in place

Next we’ll put the mitigation in place.

sudo sed -i 's/^EXTRA_JAVA_OPTS=""$/EXTRA_JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"/g' /etc/default/openhab2
sudo systemctl restart openhab2

Now we re run the check above and this time we expect it to say “true”, indicating that the mitigation is in place.

/usr/share/openhab2/runtime/bin/client -p habopen "system:property log4j2.formatMsgNoLookups"

We now expect that this will say “true”.


If you get “Failed to get the session.” in the last step, it’s likely because OpenHAB isn’t done starting up. Just wait a few minutes and try again.

Thank you @hestia_hacker !
Renamed and pinned to the top for people to see.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.