Clamav reports a malware


I’m using openhab3.

My antivirus clamav reports an alert here :

/usr/share/openhab/runtime/system/org/ops4j/pax/url/pax-url-wrap/2.6.7/pax-url-wrap-2.6.7-uber.jar: Java.Malware.CVE_2021_44228-9915814-0 FOUND

Two questions for you :

  • is it a malware on my local instance, a false positive, or a vulnerability of an openhab dependency ? searching for CVE_2021_44228, it seems that it is related to the log4j zero day vuln of high criticity : any plan to patch openhab soon if it is the case ?
  • is it normal that openhab3 relies on something 2.6 ? or do I need to cleanup something, removing older stuff after having upgraded to 3 ?

Thanks !

I suppose you could look at the related announcement

Can’t help with your detection report though

1 Like

It’s nice that ClamAV is detecting this and so soon after it was discovered. But calling it malware is totally misleading and confusing so I ding them for that.

It’s not a false positive but it’s also not malware. It’s a library that openHAB uses that has a really severe vulnerability.

See the thread that @rossko57 posted. A patch has been released for OH 3, 3.1 and 3.2 already to mitigate that CVE (but there is another log4j2 CVE that is less severe that that will need more significant changes to and testing to release).

That announcement also has instructions to deploy the patch yourself if needed (it’s really a configuration setting).

But as @rossko57 said, it won’t stop ClamAV from reporting it.

Well, as with any software, openHAB is built up with parts from lots of different projects. Each one is run by and maintained by wholly independent teams and organizations. They have their own versioning and release cycles which we have no control over.

Yes, OH relies on some 2.6 version libraries, some 0.1 version libraries, and some 5.7 version libraries. The version numbers of log4j2 or karaf, or Pax or Jax, or Jinja, or Jetty or any of the dozens of other third party libraries that it uses has nothing to do with OH’s version numberrr.


Thank you @rlkoshak and @rossko57

I’m pleased to see that openhab’s volunteer governors are mature about cybersecurity questions :slight_smile: Bravo !

That is correct as long as just the workaround/mitigation is being used.
Isn’t a real fix ( log4j latest version ) being used in that version which @Kai described

That shouldn’t be flagged any longer then.

Cancelling my message : what I was suggesting is already there :slight_smile:

“Stable” is stable, as in “won’t change”.
“Milestone” is “tested, but we want to do some more things before setting to stable”
“Snapshot” is “not well tested, latest fixes, latest new functionality, at your own risk”

It’s completely save to use milestone as a productive system, even if not recommended. Even the daily snapshots are pretty stable in the meaning of “won’t crash”.

The only thing to be aware of is, there may be changed behavior or configuration, so be careful when updating (but that is always true for all updates of all software)

I disagree Udo :slight_smile:

Stable is stable, as in “won’t change except for important things like maintaining the security or fixing critical bugs”.
Anyway, that is the case, so no problem :slight_smile: : openhab stable is 3, and a security patch has been released on the stable branch, providing a fix when updating from stable 3.1.0 to stable 3.1.1.
It has been installed well by my debian package manager.

The only thing I may recommend to change is the Download openHAB | openHAB page, still referencing 3.1.0 as stable download. It should be updated to 3.1.1, and more generally maybe with a link to the latest version of stable (instead of changing it manually on the layout of the page)

My understanding was the patch that was released and back ported was to set the flag to disable the interpretation of lookups in Log4J2. That solves the remote code execution problem but there is a denial of service issue having to do with lookups that this does not fix.

The only way to fix both and stop ClamAV (and others) from reporting it the actual library needs to be updated. For that updating Karaf is required (if I understand correctly). Since Karaf is the platform upon which all of OH runs, upgrading that is a much bigger deal with a might higher likelihood of regressions and breaking changes. And that’s not a change that is easily back-ported.

So at the earliest I wouldn’t expect to see that library updated until OH 3.2 release at the earliest, perhaps sometime after the release. And anyone running earlier versions of OH will still be running the older library.

There might be ways to update just the log4j2 library without upgrading all of Karaf so that might be the approach that is taken too. But again I doubt that will be back ported.

1 Like

I think that problem of updating pax in karaf is discussed in karaf team there

They will fix in 4.3.4 release but it seems that something built upon a former release can bump the dependency at runtime :

On Mon, Dec 13, 2021 at 2:17 PM Grzegorz Grzybek

@Steven Huypens

In order to fix in current installation, you have to change the version in
etc/ and at runtime, do update <bundle-id-of-pax-logging-log4j2> mvn:org.ops4j.pax.logging/pax-logging-log4j2/2.0.11

Grzegorz Grzybek