Zimbra Security Update

[axslingr]

Not really sure why my post got deleted either. I was just looking for clarification that I built 10.0.3 correctly since "the 3" were still installed. Maybe I got it right and somebody else didn't.

Lance

[stolen time]

I run a very small mail server using Zimbra 8.8.15 on Ubuntu 18.04.6 LTS. Prior to this patch, Zimbra was at patch 41 and Ubuntu is patched using ESM.

My system is now running normally but I had a couple of problems which I'm reporting in case that's useful to anyone looking for a common pattern.

The patch appeared to run normally, and zimbra continued normally for a few minutes after restart. Then I re-booted the server because experience shows that sometimes flushes out a few gremlins, and it did this time.

• The lesser problem was that there was something wrong with the antivirus for a while: a couple of messages came through as unchecked, and I could see a freshclam process running for longer than usual. In retrospect this may just have been an unfortunate coincidence caused by some clam update being in progress at the same time as I did the patch. It eventually sorted itself out after I had re-booted the system again for other reasons.

• The more serious problem after the reboot was that the application slowed to a crawl. I can see from the logs that the system was sending mail admin (these must have been the routine mails saying "service xxx started" ) but they were only logged at the rate of about one a second and the processing to deliver them didn't happen. At the same time, the web interface slowed to a crawl and eventually timed out. Even the console interface became slow (I couldn't see any CPU or memory hogs using top, and there were only a couple of instances of clamd and one freshclam running, so I don't really know what was causing this).

• I had to re-boot the server again to get a responsive shell, and then I ran zmcontrol stop. On a hunch that there might be some corruption in the jetty work directory, I removed the work directory (by renaming /opt/zimbra/jetty_base/work to /opt/zimbra/jetty_base/work.bak), and re-started zimbra. (This was the action that used to recover when, a few years back, patches routinely corrupted the mobile user interface). Whether because of this, or for some other reason, it's all working normally now.

[halfgaar]

When I diffed patch 41 and 42, the only difference was three 'rm' statements in the 'post install' script, so I doubt that patch caused your problems. However, patch 41 did change a bunch, so perhaps you're only now seeing it?

[stolen time]

Fair point and likely true of course, I wish I had had the knowledge and time to investigate better.

[nirt]

Hi,

Reading https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P42 appears this

If your server currently has patch 40 or an older version installed, it's important to update your servers to Patch 41 before applying this patch release. Please ensure you review Patch 41 release notes to obtain all updates on all components.

I'm not sure what different action are needed if for example you have Zimbra 8.8.15 P40, reading release notes 41 and 42 I see same steps, and I understand taht executin same steps will upgrade 40 to 42 directly, correct? If this is not correct how to ensure to execute first 41 and then 42?

Thanks

[zmcontrol]

A one-click security vulnerability in all versions of Zimbra Collaboration Suite has been discovered that could allow an unauthenticated attacker to gain access to a Zimbra account.

barrydegraaff ,

Do you know if this was discovered in the 'wild' or from audits?
If the former, are there any known mailbox.log entries to confirm an exploit attempt?
Thanks

[ghen]

I'm not sure what different action are needed if for example you have Zimbra 8.8.15 P40, reading release notes 41 and 42 I see same steps, and I understand taht executin same steps will upgrade 40 to 42 directly, correct? If this is not correct how to ensure to execute first 41 and then 42?

I think they just want to avoid people blindly patching to P42 and including eg. the OpenSSL 3.0 upgrade, without looking at the P41 release notes first...

But this is just another reason why it's so important to be more transparant about the fix for this security issue, for people on older versions who can't upgrade straight away. The mitigation instructions are already 100% public in the zimbra-patch packages in the repo, so why not just share them here as well?

[saket.patel]

Hi,

Reading https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P42 appears this

If your server currently has patch 40 or an older version installed, it's important to update your servers to Patch 41 before applying this patch release. Please ensure you review Patch 41 release notes to obtain all updates on all components.

I'm not sure what different action are needed if for example you have Zimbra 8.8.15 P40, reading release notes 41 and 42 I see same steps, and I understand taht executin same steps will upgrade 40 to 42 directly, correct? If this is not correct how to ensure to execute first 41 and then 42?

Thanks

Yes same step will upgrade you directly to patch 42, but just make sure to read and understand changes done in Patch 41 as it had openssl upgrade which could break some custom environments or customizations.

[halfgaar]

Hi,

Reading https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P42 appears this

If your server currently has patch 40 or an older version installed, it's important to update your servers to Patch 41 before applying this patch release. Please ensure you review Patch 41 release notes to obtain all updates on all components.

I'm not sure what different action are needed if for example you have Zimbra 8.8.15 P40, reading release notes 41 and 42 I see same steps, and I understand taht executin same steps will upgrade 40 to 42 directly, correct? If this is not correct how to ensure to execute first 41 and then 42?

Thanks

It's because it was a panic patch. Let me explain:

The zimbra-patch package has a 'post install' script that has three lines like:

Code: Select all

if [ -f /opt/zimbra/jetty_base/secret_file_name.jsp ]; then
    rm -f /opt/zimbra/jetty_base/secret_file_name.jsp
fi

Meaning, if file exists, remove it.

This 'post install' script is only executed after installing the package 'zimbra-patch'. Patch version 41 had updates to many packages, and if you upgrade to 42 in one go, the zimbra-patch-42 may be installed before zimbra-mbox-war, from which the three offending files actually come. This means, the deleted files will be put there again after zimbra-mbox-war is upgraded later in the sequence.

For Ubuntu 16, zimbra-patch has a dependency on 'zimbra-mbox-war (>= 8.8.15.1684213151-1.u16)'. Had they actually changed it to '8.8.15.1688663419-1.u16', the installation order would have been guaranteed.

If patches are released that are not properly installed by automatic packagers like apt, it's a bug. You just can't expect people to know that 'apt upgrade' won't fix it.

That makes it extra bad they won't allow publication of these file names. DM me if you want them, I'd say.

[jmorby]

Applying the patch 35 update seems to also install OpenSSL 3.0.9 ?? which then breaks zmcertmgr

There's a manual patch (provided by the guys at zextras) but when will Synacor push out an update that fixes this as auto renewal/SSL updates are currently failing