Hello. Regarding this vulnerability in Log4j, when we are using Openfire 4.1.4 and the log4j version is 1.2.8, what are the steps we can take to address this vulnerability?
Thank you.
We are using docker image created with openfire 4.4.0 version. So while running the docker container if we use this will it be enough?
environment:
- LOG4J_FORMAT_MSG_NO_LOOKUPS=true
or should we create a new docker image by adding the below line:
openfire_javargs="-Dlog4j2.formatMsgNoLookups=true"
Installations that are based on the RPM distribution (Red Hat, CentOS and derivatives) can be configured with a workaround as follows (note that upgrading to Openfire 4.6.5 remains the preferred solution).
These installs typically have a configuration file in /etc/sysconfig/openfire that can be used to apply additional configuration to Openfire. The default file looks something like this:
# Set this to the path where openfire lives.
# If this is not set the script will look for /usr/local/openfire, then
# /opt/openfire.
#OPENFIRE_HOME=""
# If there is a different user you would like to run openfire as,
# change the following line.
#OPENFIRE_USER="daemon"
# If you wish to change the location of the openfire pid file,
# change the following line.
#OPENFIRE_PIDFILE="/var/run/openfire.pid"
# If you wish to explictly specific the location of the log directory,
# you can set it here. Note that this applies to the logs generated outside
# openfire itself. If you want to change the location of openfire's own
# logs, see the system property 'log.directory'. If this is not set,
# it will default to $OPENFIRE_HOME/logs.
#OPENFIRE_LOGDIR="/some/where/logs"
# If you wish to set any specific options to pass to the JVM, you can
# set them with the following variable.
#OPENFIRE_OPTS="-Xmx1024m"
# If you wish to override the auto-detected JAVA_HOME variable, uncomment
# and change the following line.
#JAVA_HOME=/usr/java/default
Note that all these lines are commented out (start with a # symbol) and are thus not active.
Find the line that contains OPENFIRE_OPTS and activate it, by removing the # that’s in front of it (or duplicate the line, leaving the original line as future example). Then, modify the value of the property to include the -Dlog4j2.formatMsgNoLookups=true directive. If previously the line was commented out (the default), then you do not need to retain the example value from the example. If your instance was already using the OPENFIRE_OPTS line, then add the new option to the existing values, separating them with a whitespace character (ensure to include everything within the quote " characters).
The new file content could look something like this:
# Set this to the path where openfire lives.
# If this is not set the script will look for /usr/local/openfire, then
# /opt/openfire.
#OPENFIRE_HOME=""
# If there is a different user you would like to run openfire as,
# change the following line.
#OPENFIRE_USER="daemon"
# If you wish to change the location of the openfire pid file,
# change the following line.
#OPENFIRE_PIDFILE="/var/run/openfire.pid"
# If you wish to explictly specific the location of the log directory,
# you can set it here. Note that this applies to the logs generated outside
# openfire itself. If you want to change the location of openfire's own
# logs, see the system property 'log.directory'. If this is not set,
# it will default to $OPENFIRE_HOME/logs.
#OPENFIRE_LOGDIR="/some/where/logs"
# If you wish to set any specific options to pass to the JVM, you can
# set them with the following variable.
#OPENFIRE_OPTS="-Xmx1024m"
OPENFIRE_OPTS="-Dlog4j2.formatMsgNoLookups=true"
# If you wish to override the auto-detected JAVA_HOME variable, uncomment
# and change the following line.
#JAVA_HOME=/usr/java/default
After saving the file, restart Openfire (note this will briefly interrupt service).
# systemctl restart openfire
To check if your changes were successful issue the following command:
# ps ax | grep openfire
The output should include the formatMsgNoLookups option, like in the example below:
21214 ? Sl 0:02 /etc/alternatives/jre/bin/java -Dlog4j.configurationFile=/opt/openfire/lib/log4j2.xml -server -Dlog4j2.formatMsgNoLookups=true -DopenfireHome=/opt/openfire -Dopenfire.lib.dir=/opt/openfire/lib -classpath /opt/openfire/lib/startup.jar -jar /opt/openfire/lib/startup.jar
21254 pts/0 R+ 0:00 grep --color=auto openfire
1 Like
Installations that are based on the DEB distribution (Debian, Ubuntu and derivatives) can be configured with a workaround as follows (note that upgrading to Openfire 4.6.5 remains the preferred solution).
These installs typically have a configuration file in /etc/default/openfire that can be used to apply additional configuration to Openfire. The default file looks something like this:
# Defaults for openfire initscript
# sourced by /etc/init.d/openfire
# installed at /etc/default/openfire by the maintainer scripts
#
# This is a POSIX shell fragment
#
# If you wish to override the auto-detected JAVA_HOME variable, uncomment
# and change the following line.
#JAVA_HOME=/usr/java/default
# Additional options that are passed to the Daemon.
DAEMON_OPTS=""
Modify the value of the DAEMON_OPTS property to include the -Dlog4j2.formatMsgNoLookups=true directive. Make sure that the line does not start with a # character. If your instance was already using the DAEMON_OPTS line, then add the new option to the existing values, separating them with a whitespace character (ensure to include everything within the quote " characters).
The new file content could look something like this:
# Defaults for openfire initscript
# sourced by /etc/init.d/openfire
# installed at /etc/default/openfire by the maintainer scripts
#
# This is a POSIX shell fragment
#
# If you wish to override the auto-detected JAVA_HOME variable, uncomment
# and change the following line.
#JAVA_HOME=/usr/java/default
# Additional options that are passed to the Daemon.
DAEMON_OPTS="-Dlog4j2.formatMsgNoLookups=true"
After saving the file, restart Openfire (note this will briefly interrupt service).
# systemctl restart openfire
To check if your changes were successful issue the following command:
# ps ax | grep openfire
The output should include the formatMsgNoLookups option, like in the example below:
3173 ? Sl 0:02 /bin/java -Dlog4j2.formatMsgNoLookups=true -server -DopenfireHome=/usr/share/openfire -Dlog4j.configurationFile=/usr/share/openfire/lib/log4j2.xml -Dopenfire.lib.dir=/usr/share/openfire/lib -classpath /usr/share/openfire/lib/startup.jar -jar /usr/share/openfire/lib/startup.jar
3193 pts/0 S+ 0:00 grep openfire
1 Like
The affected version of Log4j was introduced in Openfire 4.3.0. Older versions of Openfire will not suffer from the “log4shell” vulnerability. However, older versions of Openfire suffer from different issues and vulnerabilities. Upgrading Openfire is recommended.
1 Like
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