8.8.15 Patch 31 and 9.0.0 Patch 24 Re-Released

[L. Mark Stone]

To address a remote code execution vulnerability in the Spring4Shell framework, Zimbra have re-released 8.8.15 Patch 31 and 9.0.0 Patch 24. Updated Release Notes are here:
https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P31
https://wiki.zimbra.com/wiki/Zimbra_Releases/9.0.0/P24

Details on the exploit from Trend Micro are here:
https://www.trendmicro.com/en_no/resear ... iners.html

The Release Notes say "Zimbra is not directly impacted by this issue. But given the evolving and broad nature of this issue we, have updated the following affected packages."

Hope that helps,
Mark

[JDunphy]

Thanks for posting Mark.

Even more confusing to me is that: https://wiki.zimbra.com/wiki/Security_Center
has been updated yesterday to remove a previous warning that they could not reproduce the exploit. The only mention of this CVE is in patch 24 for version 9 with that new wording being added Apr 21, 2022. There is no 8.8.15 notes on this nor guidance in that security_center document. Not even a mention that they have a hot fix and a reissued patch 31.

As with all patches, they ask us to take snapshots or backups, test it in case something goes wrong so any patch/change to zimbra isn't something one does lightly given the human cost for users and staff unless it is absolutely required. As a network partner, do you know the risk to 8.8.15 patch 31 installs? Given their own security documentation doesn't think it is important enough to mention re-applying patch 31, I am on the fence of what to do. For many smaller commercial customers like myself, we prefer to do patches on the weekend in early mornings whenever possible because our users and systems are underutilized at this time and hopefully less disruptive to our enterprises. Zimbra has no support on weekends for our license type so if you don't test every patch extensively and a patch creates an outage you are on your own until you fix it so even a hotfix which seems rushed given the re-issued nature of this patch requires one to be cautious. Sorry that last part was a little venting with my frustration of this product with how they mix security, feature updates, and bug fixes from time to time in the same patch.

Jim

[L. Mark Stone]

Thanks for posting Mark.

Even more confusing to me is that: https://wiki.zimbra.com/wiki/Security_Center
has been updated yesterday to remove a previous warning that they could not reproduce the exploit. The only mention of this CVE is in patch 24 for version 9 with that new wording being added Apr 21, 2022. There is no 8.8.15 notes on this nor guidance in that security_center document. Not even a mention that they have a hot fix and a reissued patch 31.

I think that's an error of omission for 8.8.15 in the Security Center wiki, because the 8.8.15 Patch Release Notes says the Spring fix is in 8.8.15.

As with all patches, they ask us to take snapshots or backups, test it in case something goes wrong so any patch/change to zimbra isn't something one does lightly given the human cost for users and staff unless it is absolutely required. As a network partner, do you know the risk to 8.8.15 patch 31 installs? Given their own security documentation doesn't think it is important enough to mention re-applying patch 31, I am on the fence of what to do. For many smaller commercial customers like myself, we prefer to do patches on the weekend in early mornings whenever possible because our users and systems are underutilized at this time and hopefully less disruptive to our enterprises. Zimbra has no support on weekends for our license type so if you don't test every patch extensively and a patch creates an outage you are on your own until you fix it so even a hotfix which seems rushed given the re-issued nature of this patch requires one to be cautious. Sorry that last part was a little venting with my frustration of this product with how they mix security, feature updates, and bug fixes from time to time in the same patch.

Jim

I'll be installing the rereleased patch this weekend. My biggest concern is with the same_site_cookie setting, which I am going to set to Lax for the moment.

My experience is that many vendors release patches with a mix of feature updates, bug fixes and security improvements, but I take your point about Support.

At least in my US VAR price book, the difference between Standard Support (NBD coverage) and Premiere Support (24x7x365 for system outages i.e Sev-1 cases) is couch money. The only time I sell Standard Support instead of Premiere is when the customer is a true 9-5/M-F company and where, if email were down for a day or two, it would not be the end of the world. I show prospects both prices and let them decide, because (having been a CIO) it's not my place to dictate to a customer how much risk they should mitigate, but I do feel an obligation to give the customer options to mitigate different levels of risk at different price points.

Plus, those of us with some grey hair know full well that system crashes always happen either right before a tight deadline (like closing out the end of year), or on the Friday late afternoon of a 3-day weekend, right? So for most customers, Premiere Support is a kind of "cheap insurance".

All the best,
Mark

[JDunphy]

FYI,

Re-applied patch 31 to my commercial version. Uneventful here. Still monitoring. Need to wait for my tripwire reports to see everything touched. I did need to re-apply my amavis.conf patch and skins (theme) patch but I have become accustomed to see those scripts fire after every update and be re-applied. My other modifications to the mta (main.cf, etc) were left untouched. Retested 2FA and it worked also without issue. Not a lot of testing yet.

Did double check zimbra_same_site_cookie and it retained it's previous value from patch 31.

Code: Select all

Upgrading:
 zimbra-common-core-jar                       x86_64                      8.8.15.1650521520-1.r8                            zimbra-8815-oss                           13 M
 zimbra-common-core-libs                      x86_64                      8.8.15.1650522012-1.r8                            zimbra-8815-oss                           64 M
 zimbra-mbox-ews-service                      x86_64                      8.8.15.1650522147-1.r8                            zimbra-8815-network                      1.3 M
 zimbra-mta-patch                             x86_64                      8.8.15.1650529377.p31-1.r8                        zimbra-8815-oss                           24 k
 zimbra-patch                                 x86_64                      8.8.15.1650529377.p31-2.r8                        zimbra-8815-network                       99 M

Transaction Summary

The only bug I could find thus far is version. If a user leaves them self logged in with the web interface, they are presented with this information and told to refresh:

Code: Select all

Old version: 8.8.15_GA_4257 20220324034943 20220324-0437 NETWORK
New version: 8.8.15_GA_4266 20220421024309 20220421-0321 NETWORK

Yet after they login/logout or refresh they are told they are running version 8.8.15_GA_4257 when they use About to verify what version. Should say version 4266. The admin interface About does show the correct version 4266.

Code: Select all

# su - zimbra
% zmcontrol -v
Release 8.8.15_GA_3953.RHEL8_64_20200629025823 RHEL8_64 NETWORK edition, Patch 8.8.15_P31.

zmcontrol reports something entirely different. I guess testing version numbers isn't something they do. That must make it interesting for support.

Jim

[L. Mark Stone]

Jim,

I also applied the rereleased patch 31 on 8.8.15…

zmcontrol -v will give different version numbers based on the operating system and package mix installed in my experience.

I have two Ubuntu 20 mail stores that report 8.8.15.GA.4177. An Ubuntu 18 mail store reports 8.8.15.GA.3869.

And as I know you know, unless the store package is installed, zmcontrol -v won’t give you any patch level information.

All the best,
Mark

[edisu]

did anyone found any issue/bugs on this 8.8.15 Patch 31 re-released?

[omegainstitute]

did anyone found any issue/bugs on this 8.8.15 Patch 31 re-released?

Only thing I had to do was flush the jetty/work folder for my mobile users (ztaglib.TAG_EXCEPTION issue). Other than that it's been flawless.

[edisu]

did anyone found any issue/bugs on this 8.8.15 Patch 31 re-released?

Only thing I had to do was flush the jetty/work folder for my mobile users (ztaglib.TAG_EXCEPTION issue). Other than that it's been flawless.

how did you flush the jetty/work folder? Do i need to worry about this issue? What is your zimbra environment is it single server or multi-node server?

[omegainstitute]

did anyone found any issue/bugs on this 8.8.15 Patch 31 re-released?

Only thing I had to do was flush the jetty/work folder for my mobile users (ztaglib.TAG_EXCEPTION issue). Other than that it's been flawless.

how did you flush the jetty/work folder? Do i need to worry about this issue? What is your zimbra environment is it single server or multi-node server?

You may or may not have an issue with this. Many previous updates for me have been flawless. This was the first time I've had to do the flushing.

My environment is a single FOSS installation servicing about 300 people.

If, after you patch to the latest version, you start getting errors like:

ztaglib_TAG_EXCEPTION.png (56.14 KiB) Viewed 2833 times

Do the following to flush the jetty/work folder:

Code: Select all

su - zimbra
zmcontrol stop
mv /opt/zimbra/jetty/work /opt/zimbra/jetty/work.old
mkdir /opt/zimbra/jetty/work
chown zimbra:zimbra /opt/zimbra/jetty/work
zmcontrol start

Again, you may not have to do the procedure above.