Thanks @guus for a quick turnaround on this. We were able to test this on a standalone box. One way to verify that the setting has taken effect is to have latest java sdk installed and run the command “jinfo (pid of the openfire service)” - You should see this parameter “-Dlog4j2.formatMsgNoLookups=true” in the output.
1 Like
I’m using OF on Windows Server. Right after I read about CVE in Log4j I added the parameter in the .vmoptions file.
Today I have successfully updated OF to the latest version 4.6.5. Should I delete this very parameter in the .vmoptions file of should I leave it for the future?
I see that this version of Openfire updated log4j to 2.15.
What about the new concerns that 2.15 doesn’t fix the issue completely Log4j – Apache Log4j Security Vulnerabilities? Is 4.6.5 affected? Will a new version of Openfire be released with a log4j 2.16 upgrade?
I can’t see how having that system property in the vmoptions file can do any harm. We’re preparing for another update to log4j in Openfire, in which we also include setting this property (as well as adding another mitigation strategy: disabling lookups in the message convertor). Doing all of these probably is redundant - but then again, I’m not seeing any harm in applying these either. Given that Openfire is very customizable, I’m thinking I rather have surplus layers of protections, rather than one to few.
For anyone that has thoughts on the matter, please leave a comment here, or on the proposed change in OF-2353: Upgrade to log4j2 2.16.0 and adding various mitigation actions by guusdk · Pull Request #1946 · igniterealtime/Openfire · GitHub
An update from 2.15.0 to 2.16.0 is being prepared for in OF-2353: Upgrade to log4j2 2.16.0 and adding various mitigation actions by guusdk · Pull Request #1946 · igniterealtime/Openfire · GitHub. As I understand things, the vulnerability that is fixed by this only applies to very specific applications of Log4j (which Openfire doesn’t do), and that it’s nowhere near as scary as the vulnerability fixed with 2.15.0.
2 Likes
Thanks. Any concerns about log4j-api? I see that Openfire 4.6.5 uses log4j-api 2.14 and when scanning it, it flags vulnerability CVE-2021-44228 with a score of 9.8… Should I be concerned about this or consider it a false positive since log4j-core has been upgraded to 2.15?
I’m assuming that you mean ‘2.15.0’ instead of ‘2.14’. As I wrote yesterday, an upgrade to 2.16.0 is in the works.
I actually meant 2.14. But it was my scan’s issue, it was wrongly mapped. Sorry, ignore that, and thank you for the fast replies.
Please note that moments ago, we’ve released a new version of Openfire that adds better protection against the Log4j vulnerabilities. Read all about it on https://discourse.igniterealtime.org/t/openfire-4-6-6-and-4-5-5-releases-log4j-only-changes/
Are there any updates planned for the Spark application? It seems to be utilizing the log4j library as well. I’m sure it is of lesser importance, since there really shouldn’t be any clients that are exposed publicly. But from a compliance standpoint I’m having to account for everything.
You mean the jingle plugin for Spark?
Where did you find that? Spark should not use Log4j at all, so there should not be any updates needed.
The old Jingle plugin (which hasn’t been part of the Spark distributable for quite some time) did have a log4j library associated to it, but that was a version of Log4j that was so old, that it doesn’t suffer from the vulnerabilities that were discovered last week.