Hi everyone,
has anyone looked into CVE-2021-44228? I believe openHAB could be affected by this aswell so this should be addressed before the next release.
@Kai please keep this in mind when planning the next release.
Hi @Flole,
That’s a good point, this CVE makes quite some high waves today.
We should indeed check how we can address it for 3.2.
Unfortunately, we are using Karaf, which in turn uses OPS4J Pax Logging, which builds on top of log4j (currently only version 2.0.10) - so we have a nasty dependency chain here, which isn’t easy to resolve.
@wborn Would you see any way how we could possibly update to 2.15.0 without having to wait for the other projects to do new releases?
If we can’t find a good way to upgrade, we should be able to mitigate the vulnerability - according to the advisory, it is possible to set the system parameter log4j2.formatMsgNoLookups to true for this.
1 Like
FTR: PAX Logging has already been fixed with a new release: [CVE-2021-44228] Upgrade to log4j2 2.15.0 · Issue #414 · ops4j/org.ops4j.pax.logging · GitHub
2 Likes
That means Karaf is the next link in the chain which needs to update, right? I think the issue for that over at karafs issue tracker is [KARAF-7262] Upgrade to Pax Logging 2.0.11 - ASF JIRA, not sure how they managed to create that issue before 2.0.11 was even released… It’s targeted for Karaf 4.3.4, not sure which version we are using but maybe it’s a good idea to comment on that issue to stress that this is important as it fixes that CVE.
I think instead of updating to an untested Karaf version it might be better to use the workaround for now and then for the next release include the fix. Updating Karaf seems to be a bigger change that should be tested with a Milestone and not just thrown into a release kinda last minute IMO.
1 Like
Is there something, that we (users) can do with the actual 3.1 release?
Is the openhab-cloudservice affected ?
That is a great question. I would assume (and this is only an assumption!) that you can add
-Dlog4j2.formatMsgNoLookups=true
to the EXTRA_JAVA_OPTS in /etc/default/openhab. If you are still on openHAB 2.x then that file would be /etc/default/openhab2.
For example:
EXTRA_JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"
If this is confirmed as a fix this should be posted as an anouncement. The cloud service is based on node.js IIRC, so it shouldn’t be affected. OHs Demo Instance could be affected though.
in which file you mean to add the option?
Are you on WIndows or Linux? For Linux I stated the file for OH 3.x and 2.x, for Windows I would have to double-check. I’d guess it’s in the start.bat and start-debug.bat (assuming those files still exist).
Windows …running as a service with the service-wrapper…
openHAB-wrapper.conf ?
or setenv.bat ?..there is already a EXTRA_JAVA_OPTS section
@Flole Right, I just found the very same Karaf issue and commented on it. We are currently on 4.3.3, so upgrading to 4.3.4 would be a logical step. I assume that they are working on that release right now.
Is the openhab-cloudservice affected ?
@RalphSester No, this is using node.js, no Java.
For Windows it should be (again, just guessing here) openHAB-wrapper.conf, and the syntax there is a little different:
wrapper.java.additional.XX=-Dlog4j2.formatMsgNoLookups=true
where XX is the next available number in the sequence of lines. So if you have
# Java Parameters
wrapper.java.additional.1=-Dkaraf.home="%KARAF_HOME%"
wrapper.java.additional.2=-Dkaraf.base="%KARAF_BASE%"
wrapper.java.additional.3=-Dkaraf.data="%KARAF_DATA%"
wrapper.java.additional.4=-Dkaraf.etc="%KARAF_ETC%"
wrapper.java.additional.5=-Dcom.sun.management.jmxremote
wrapper.java.additional.6=-Dkaraf.startLocalConsole=false
wrapper.java.additional.7=-Dkaraf.startRemoteShell=true
wrapper.java.additional.8=-Dopenhab.home="%OPENHAB_HOME%"
wrapper.java.additional.9=-Dopenhab.conf="%OPENHAB_HOME%\conf"
wrapper.java.additional.10=-Dopenhab.runtime="%OPENHAB_HOME%\runtime"
wrapper.java.additional.11=-Dopenhab.userdata="%OPENHAB_HOME%\userdata"
wrapper.java.additional.12=-Dopenhab.logdir="%OPENHAB_USERDATA%\logs"
wrapper.java.additional.13=-Dfelix.cm.dir="%OPENHAB_HOME%\userdata\config"
wrapper.java.additional.14=-Dorg.osgi.service.http.port=8080
wrapper.java.additional.15=-Dorg.osgi.service.http.port.secure=8443
wrapper.java.additional.16=-Djava.util.logging.config.file="%KARAF_ETC%\java.util.logging.properties"
wrapper.java.additional.17=-Dkaraf.logs="%OPENHAB_LOGDIR%"
wrapper.java.additional.18=-Dfile.encoding=UTF-8
as mentioned in the documentation you should add
wrapper.java.additional.19=-Dlog4j2.formatMsgNoLookups=true
ok - thank you…i will test it.
I have set the parameter in the openHAB-wrapper.conf and restarted the service.
Everything seems fine again.
Is there a way, which i can test, if the parameter is active in the running instance?
I would guess it can be checked on the karaf console using
system:property log4j2.formatMsgNoLookups
which should say “true” and not “null”.
its “null”
Sorry that command was wrong, that “org.” shouldn’t be there. I corrected my post.
ok…now it’s “true” 
so could that now be called a “solution”?
What side effects can the parameter cause in OpenHAB?
Can I test this somehow?
Cool, thanks for testing, guys.
@Flole Could you do a PR against openhab-distro with that? We would then have the snapshots already covered.
I’m also thinking about doing a 3.1.1 patch release with this, if I can get that going.
For 3.2, I’d then hope for Karaf 4.3.4 becoming available on time.
Don’t take this as speaking against anything discussed here regarding fixes and mitigations and such.
But my reading of this is that it’s only an issue if log4j2 is configured to use a JNDI service. My reading of log4j2.xml is that the OH config, by default, does not use and JNDI in the configs. So the actual exposure to most of our users to this CVE is limited to those who have modified log4j2.xml to use JNDI features.
Given that, in any announcement made and whatnot we need to be careful not to scare everyone about their system having already been hacked or something like that. For those who have modified log4j2.xml it’s prudent to add the environment variable until the fix rolls out. For the rest, it’s probably a good idea but not critical because they haven’t actually had any exposure to it to date.
Of course this all goes out the window if OPS4J Pax. Logging or Karaf do some JNDI stuff in code or outside of the exposed log4j2.xml config.
1 Like
Thanks for joining in @rlkoshak! You raise a good point. I am actually not sure how the JNDI is activated and used in this context. So I guess you’re right and it makes sense to dig a bit deeper to really understand the issue first in detail.
My reading of log4j2.xml is that the OH config, by default, does not use and JNDI in the configs.
Could you elaborate on this, please? Does JNDI have to be activated in the xml to be a problem?