Openfire 4.6.6 and 4.5.5 releases (Log4j-only changes)

[guus]

As we’re monitoring developments around the recent Log4j vulnerabilities, we’ve decided to provide another update for Openfire to pull in the latests available updates from Log4j.

Since the previous release, the Log4j team released a new version (2.16.0) of their library, that provides better protection against the original vulnerability (CVE-2021-44228), but also guards against a newly discovered vulnerability (CVE-2021-45046) in Log4j.

The Ignite Realtime community has decided to immediately make available new releases of Openfire that include this newer version of Log4j: Openfire 4.6.6 and Openfire 4.5.5.

In addition to upgrading the Log4j libraries to version 2.16.0, we have put in place the mitigation measures that were defined for these CVEs. It’s important to note that these mitigation measures are known to be insufficient to fully protect against the vulnerabilities. However, the update to version 2.16.0 of Log4j makes these measures redundant. We have opted to include them anyway, as we know that many of you modify Openfire to a great extent. If such modifications would inadvertently re-introduce a vulnerable version of Log4j, at least some mitigation is in place. No changes other than these Log4j-related changes are included in the releases that we are publishing today.

We are aware that for some, the process of deploying a new major version of Openfire is not a trivial matter, as it may encompass a lot more than only performing the update of the executables. Depending on regulations that are in place, this process can require a lot of effort and take a long time to complete. To facilitate users that currently use an older version of Openfire, we are also making available a new release in the older 4.5 branch of Openfire that pulls in the Log4j update. An upgrade to that version will, for some, require a lot less effort. Note well: although we are making available a new version in the 4.5 branch of Openfire, we strongly recommend that you upgrade to the latest version of Openfire (currently in the 4.6 branch), as that includes important fixes and improvements that are not available in 4.5.

The following sha256 checksums are valid for the Openfire 4.6.6 distributables:

507b4899fb1c84b0ffd95c29278eeefd56ac63849bb730192b26779997ada21b  openfire-4.6.6-1.i686.rpm
d2913d913449a9e255b10ea6ee22a5967083a295038c21d3b761bb236c22e0cd  openfire-4.6.6-1.noarch.rpm
02aa7af09286f25fbceef1ea27940e1696ced1e3a6c28b5e0ae094d409580734  openfire-4.6.6-1.x86_64.rpm
3add3c877745dcc6aacd335cfc8fe1674567bb3b28728cfa6c008556c59a9e98  openfire_4.6.6_all.deb
00c5ecbbf725de1093bfe3e5774b8c0e532742435439f70a4435fc5bed828b99  openfire_4_6_6_bundledJRE.exe
4ff92208e62f0455295a8cf68d57e2d9e3ede15c71aaab26cf1a410dce5aba5b  openfire_4_6_6_bundledJRE_x64.exe
2584a6b61f0d9447a868f9bfadb5892d56d854198604b3ace9b638b8c217cac4  openfire_4_6_6.dmg
6cc42bfb60a5f8453c37d980c24c2a5ba48e1e1363ebfcc5d7f2e1deb6da5f17  openfire_4_6_6.exe
6431a22d2dd9f077b9b2ee8949238c0f076ab34d43ee200a6873fa5453630bd6  openfire_4_6_6.tar.gz
ec8da5fdc93065df9bf41c0f4aebd6bb47f1dea11dcc96665ac0105f035378b2  openfire_4_6_6_x64.exe
af68252b98b8af6afb0753b4054adcf4cab1968579eaaf644d4da663e9461dce  openfire_4_6_6.zip

For Openfire 4.5.5, the sha256 checksums are:

247f0769e0a449c698ac9c23b658a02131ac6f774f4394dc9bb4e7f114159cc8  openfire-4.5.5-1.i686.rpm
4603f92ce9822d1f43d27a9e15b859232cd09f391e9aeef0b99a782a03ecd12e  openfire-4.5.5-1.noarch.rpm
9df54cbef30664635ed2977a21beded56fa120c5ff9e89b4cfa7466171344517  openfire-4.5.5-1.x86_64.rpm
0815f07094fcfaf4e17aca3ea26f42835b5ff1b486475aff6b743e914709e788  openfire_4.5.5_all.deb
dff2e81da7457e3d8c1ee9e23ff43dd812f56db09df53588df7a5ea5622b1e6e  openfire_4_5_5_bundledJRE.exe
96c2a4f5ed94dda76942ec7e540430c505448a2625a10f52cdc91c2dae0f720a  openfire_4_5_5_bundledJRE_x64.exe
a1ddd675b24b661186645786d1489cb6d80c90c2cae178992af509b5241fb275  openfire_4_5_5.dmg
971b97bc9d405a03d2c3fba51a698cf92397b24104b28fec06b993b6d52568ce  openfire_4_5_5.exe
a5f199bf2347725b952a995c1cfbeb1b8e45c9a26c177100669eeed7679da742  openfire_4_5_5.tar.gz
b5b55c5938b430fa50c702da6b8336be7f79d2c97eb09623dc0c9bd59663aead  openfire_4_5_5_x64.exe
44f90a4f4f7ecebd7cffadc7f108e4bcb8b70dc77b36698d48efaf3eb7650c91  openfire_4_5_5.zip

The process of upgrading is outlined in the Openfire upgrade guide. If you would prefer to enlist support in applying this update, various professional partners are available that can help.

We are 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!

[Kevin_Kretz]

I upgraded two openfire instances. On 15 Dec I upgraded both from 4.5.4 to 4.6.5. Today I rebuilt one of those and installed 4.6.6. They’re both openSUSE and I used the x86_64 rpm files to upgrade/install.

The first one, whose RPM shows to be 4.6.5, says 4.5.4 on the admin page. The second one says 4.6.5 on the admin page. They’ve been restarted since install/upgrade.

Where does the server version come from? Could a config file or something in the DB be causing it to report the wrong version?

thanks

Kevin

[guus]

Can someone else reproduce this? The version numbers are hard-coded. I can’t think of a reason why they would be different in different installers of the same version.

When I run from code, I seem to get the correct versions (both on the login screen, as well as in the top-right corner of the index page of the admin console)

For 4.6.5:

For 4.6.6:

(click for zoom)

[Kevin_Kretz]

On one server I see 4.5.4 and 4.6.5 jar files under /opt/openfire/lib. On the other I see 4.6.5 and 4.6.6 jar files. I also see both version of (for example) xmppserver-4.x.x running.

Doesn’t upgrading with rpm remove earlier versions? Or did I upgrade wrong?

[akrherz]

The RPM upgrade scripts struggle with stopping and starting openfire during the upgrade. Please stop openfire and then start it again, all will likely be well. The procedure I use is

systemctl stop openfire
dnf localupdate openfire...rpm
systemctl daemon-reload
systemctl start openfire

[Kevin_Kretz]

I’d already started uninstall/reinstall but this time I removed /opt/openfire and the verions are showing as expected.

Sorry for the false alarm

[wroot]

There is a new DoS vulnerability with 7.5 score in 2.16 and 2.17 is required now. The battle is not over yet… Log4j – Apache Log4j Security Vulnerabilities

[guus]

@wroot

DoS vulnerability with 7.5 score in 2.16

I do not believe that this vulnerability (CVE-2021-45105) is applicable to Openfire. It seems to apply only to instances that have a very specific configuration (that Openfire does not have).

[nobby6]

Still,
Better to not risk, the risk, and update.

Also of note, some networks (like ours) scan for vulns regulary with progs like nessus which will fire on this, which in some cases could cause a non-java-clued-in system admin to kill off the clients service until its updated

[guus]

Openfire will have the update, but as things stand today, I’m not foreseeing a need to immediately push a new release for Openfire that includes it (like we did, twice, to get updated to 2.16).

[claude_stabile]

@guus Thanks & Congrats for latest OF 4.6.6
with latest patched log4j version 2.16
FYI :
I have upgraded 15+ instances / docker mode to Openfire 4.6.6 without problems
Thanks a lot for big efforts in a very short and responsive time !!!

++

[Chrees]

@guus
Hello,
I’ve upgrade my instance firstly to 4.6.5 15 Dec, finally to 4.6.6 17 Dec.
Today I got reports that the system is not working. Users could not log in, and those logged in did not receive messages.
I restarted the service and everything was back to normal.
This has already happened the second time. The first was after updating to version 4.6.5. Before this upgade, there was no such problem.
Can I ask for help, where to look for the problem?

[guus]

@Chrees You could create a new topic in our forum that includes the details, and ask for help there. Make sure that you include as much relevant details, such as error messages and log files, and ideally a way to reproduce the problem, as possible.

If you do not want to depend on community-provided support, then you could enlist the help of one of our professional support providers.