Openfire 4.6.5 released

guus · December 10, 2021, 6:40pm

Although we’re preparing for the Openfire 4.7.0 release, the recently discovered vulnerability in the Apache Log4j utility prompted us to push an immediate release of Openfire to address that issue. This release, Openfire 4.6.5, is available now.

We urge you to update as soon as possible. If that’s not feasible, then we advise you to apply the documented workaround (in the form of adding the following argument in the start script for Openfire: -Dlog4j2.formatMsgNoLookups=true) and/or look into applying other mitigating actions.

The process of upgrading is outlined in the Openfire upgrade guide. Please note that, if desired, a significant amount of professional partners is available that can provide commercial support.

You can find Openfire release artifacts on the download page. These are the the applicable sha256sums:

926e852abfe67970a4a64b7a58d16adbd3ae65269921288909d2a353457ac350  openfire-4.6.5-1.i686.rpm
5041fd66f5cf4642d25012642d827ad80c40057ba66f79aad04918edc94085ec  openfire-4.6.5-1.noarch.rpm
f1d7ed2d5d5bbd12c3af896329df48f97b73ae5435980b524248760a246552f6  openfire-4.6.5-1.x86_64.rpm
da113f737514457209194024f57a90f52f499fefbf0a9eb3e3d888b24f214ece  openfire_4.6.5_all.deb
c16e13348767b489aef905d912eafca9650428af16a729b63a208fdbe97c9783  openfire_4_6_5_bundledJRE.exe
e03cd4e5b2a76b203540580ca2714541ee86b1ef3b677d5c312d099567674f2d  openfire_4_6_5_bundledJRE_x64.exe
28d628db9cce3cfb7acfa19977235b569729bcebff65a511dd882a4c1b554d6c  openfire_4_6_5.dmg
cb1c4a5f888cbeeb6bbfd29460c8095941cecddd8c5f03b3d3f1ca412a995e81  openfire_4_6_5.exe
fcc3d45e9b80536b463fedbb959ff1e4f5fc5cef180502f6810c0f025a01f4ac  openfire_4_6_5.tar.gz
fe216d1eecb23050ebbf28f7afa8930ca167d99516051c3f5e03d545e183cf4c  openfire_4_6_5_x64.exe
fd0f853b249a8853da51b056f1e6b31d04c49763394321dbd60abb8cef9df940  openfire_4_6_5.zip

Apart from addressing the log4j issue, this release includes a small number of other modifications, as documented in the changelog.

We’re always happy to hear about your experiences, good or bad! Please consider dropping a note in the community forums or hang out with us in our web support groupchat.

For other release announcements and news follow us on Twitter

Hans-Dieter · December 11, 2021, 8:42pm

@guus, I am not able to upgrade right now, how/where do I find the start script and how to add this ? I am running OF on Debian

Thank you.

Hans-Dieter · December 11, 2021, 9:05pm

@guus,
all ok, found and added the argument to the start-up script. Server has started successfully.

tuaris · December 12, 2021, 11:35am

For anyone using the FreeBSD port, add this to your /etc/rc/conf

openfire_javargs="-Dlog4j2.formatMsgNoLookups=true"

The do:

service openfire stop
service openfire start

Atagoman · December 13, 2021, 3:36am

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.

nipun_reddy · December 13, 2021, 5:05am

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"

talhabilalsheikh · December 13, 2021, 6:48am

Hi @Hans-Dieter , could you please tell in which file should we add this command, please help

talhabilalsheikh · December 13, 2021, 6:53am

Hi @guus, could you please tell in which file should we add this command, please help

guus · December 13, 2021, 9:10am

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

guus · December 13, 2021, 9:10am

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

guus · December 13, 2021, 9:14am

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.

guus · December 13, 2021, 9:19am

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.

talhabilalsheikh · December 13, 2021, 9:22am

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?

guus · December 13, 2021, 10:35am

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.

talhabilalsheikh · December 13, 2021, 2:15pm

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.

Hans-Dieter · December 13, 2021, 2:40pm

@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.

onesolo · December 14, 2021, 2:54pm

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…

Allen_Seelye · December 14, 2021, 3:58pm

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...

guus · December 14, 2021, 4:22pm

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.

guus · December 14, 2021, 4:24pm

@Allen_Seelye I think that’s basically the same as what is suggested in my post above?