The best course of action is to update to Openfire 4.6.5 (or later). I’m not exactly sure what the best course of action to put in place the working in Docker containers is. Various Google results suggest that setting that environment variable would be sufficient, but I have no experience there.
Hi @guus , thanks for your reply, we are using the openfire for windows, and the files you mentioned based on the DEB distribution or RPM distribution installations are not available for windows, could you please help us about the file in which we need to add this command for windows?
Installations that are based on a EXE distribution (Microsoft Windows) can be configured with a workaround as follows (note that upgrading to Openfire 4.6.5 remains the preferred solution).
Create a new file in the bin directory of Openfire (typically: c:\Program Files\Openfire\bin). The first part of the name of this file should match the command that is used to start Openfire. If you’re running Openfire as a service, that is very likely openfire-service, otherwise it’s probably openfire or openfired. The file extension needs to be vmoptions. The full file name would, for example, be: openfire-service.vmoptions (be careful to not accidentally add the .txt extension).
The content of this file can be a single text line that is:
-Dlog4j2.formatMsgNoLookups=true
If the file already exists, simply add this as a new line in the file.
Restart Openfire to apply the configuration change.
At this time, I’m not sure how to verify that the setting has taken effect. If anyone can provide insights on that, then I’d appreciate your feedback! As suggested by @Vinay_DS below, one way to verify if the setting has taken effect is to use the jinfo command (that’s part of most Java distributions). Use jinfo (pid of the openfire service) and you should see this parameter -Dlog4j2.formatMsgNoLookups=true in the output.
4 Likes
thank you @guus , i have done this and restarted the openfire server. I will let you know if we are able to verify the fix on windows.
@talhabilalsheikh , the start-up script on my Debian install is at /etc/init.d/openfire
look through the file and you will see one line starting with Dlog4j…
and add the argument -Dlog4j2.formatMsgNoLookups=true below that line and end it with a “” as it is with the original line I mentioned. You will see.
Stop & Start the server.
On 4.6.4 every two or three days, openfire stale and no one could login to the server… this happens on a win64 2k8 server, the openfire is x64 with x64 java inbuilt. I had everytime to stop and start the service again. Any ideas why? I installed 4.6.5 to see if it solves anything…
On Debian, you don’t need to edit /etc/init.d/openfire. Rather, open /etc/default/openfire, and look for DAEMON_OPTS="".
The script at /etc/init.d/openfire looks to this variable for additional command line arguments.
Change this to read: DAEMON_OPTS="-Dlog4j2.formatMsgNoLookups=true"
Now run:
sudo systemctl restart openfire
Give it a few seconds, and then verify the option was added by running:
sudo systemctl status openfire
If Openfire started successfully, and you see “-Dlog4j2.formatMsgNoLookups=true” in the output, you’re good to go.
openfire.service - LSB: Start/stop openfire jabber server
Loaded: loaded (/etc/init.d/openfire; generated)
Active: active (running) since Tue 2021-12-14 08:50:07 MST; 5min ago
Docs: man:systemd-sysv-generator(8)
Process: 8583 ExecStart=/etc/init.d/openfire start (code=exited, status=0/SUCCESS)
Tasks: 132 (limit: 9830)
Memory: 1.3G
CGroup: /system.slice/openfire.service
└─8591 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -Dlog4j2.formatMsgNoLookups=true...
This seems unrelated to the Openfire upgrade, and possibly related to the environment itself, somehow. My advise would be to investigate the log files for clues. Please create a new topic in the forum for this issue, so that we can separate concerns.
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.