Blog
What We Know About the Zero-Day Vulnerability Affecting Zimbra Collaboration and cpio
Table Of Contents
On September 10, an attack was reported in the Zimbra forums where a malicious actor was able to upload a JSP web shell into the /public directory to execute a command, generating a pre-authentication key to login to an existing account. The attack vector was a specially crafted TAR archive, which was sent with a .jpg extension as an email attachment.
RCE bug in Zimbra Collaboration Suite (CVE-2022-41352, VulnDB 302181)
The content of the TAR archive shows that it includes a symlink to the jetty/webapps/zimbra/public/ directory to which the JSP web shell is extracted.
Based on the provided information, the amavis email content filter identifies the ‘pax’ package as missing, and issues a warning message as it uses ‘cpio’ as a replacement, which Zimbra states “can be a security risk.”
News publications report that the zero-day vulnerability RCE in Zimbra Collaboration Suite is being actively exploited by threat actors. But instead of releasing a security advisory, Zimbra has responded by publishing a blog post advising users to ensure that the ‘pax’ package is installed in order to avoid using cpio. However, does doing so actually address the vulnerability?
Investigating the root cause of the vulnerability
This raises the question: Which component actually causes the vulnerability? At first sight, there are several components in play that are obvious suspects.
- Zimbra for using an insecure setup
- amavis for using cpio despite being insecure
- cpio for insecurely extracting an archive
Without having access to a Zimbra Collaboration installation, we checked the amavis source code to look for known vulnerabilities in cpio. And according to known details, CVE-2015-1197 sounds exactly like the issue that was exploited. However, according to VulnDB, the issue is fixed in version 2.13 which was released November 2019. Notably, the issue affects ‘cpio’, even when using the –no-absolute-filenames command-line option, which was introduced to create all files relative to the current directory.
Next, we checked whether amavis actually uses this option, and in lib/Amavis/Unpackers.pm, it invokes ‘cpio’ with the –no-absolute-filenames option.
At this point, we needed to put cpio to the test. Based on the initial report and similar symlink attacks, we generated a tar file that would extract a JSP file to an arbitrary directory on the system.
$ mkdir -p /tmp/jetty/webapps/zimbra/public/
$ ln -s /tmp/jetty/webapps/zimbra/public/
$ echo "test" > public/ws.jsp
$ tar cf public.tar public public/ws.jsp
Then, we passed this to the ‘cpio’ utility on an Ubuntu 20.04.4 LTS to test this with a temporary directory.
$ ls /tmp/jetty/webapps/zimbra/public/
$ $ cpio -i < public.tar
4 blocks
$ ls /tmp/jetty/webapps/zimbra/public/
ws.jsp
According to the documentation, the file should not be written to the /tmp/jetty/webapps/zimbra/public/ directory when the --no-absolute-filenames option is used.
$ ls /tmp/jetty/webapps/zimbra/public/
$ cpio -i --no-absolute-filenames < public.tar
4 blocks
$ ls /tmp/jetty/webapps/zimbra/public/
ws.jsp
This is strange. Searching for information on the mailing list shows at least one post claiming that the issue is still not fixed. It also revealed that after a bug report, the developer suggested reverting the patch that fixes the vulnerability.
We downloaded the source code and built ‘cpio’ version 2.13 to see if the issue was fixed or not. Surprisingly, everything worked as expected:
$ ls /tmp/jetty/webapps/zimbra/public/
$ ./cpio-2.13/src/cpio -i --no-absolute-filenames < public.tar
./cpio-2.13/src/cpio: Removing leading `/' from hard link targets
./cpio-2.13/src/cpio: public/ws.jsp: Cannot open: No such file or directory
4 blocks
We didn’t see that coming. Since our Ubuntu release comes with cpio version 2.13, something was wrong with the Ubuntu cpio package.
We checked the Ubuntu package files downloaded from https://packages.ubuntu.com/ and indeed, the patch for CVE-2015-1197 was reverted.
$ ls -1 debian/patches/
218086-reporting-bugs.patch
588020-manpages-see-also.patch
695717-no-cpio.info-2.patch
695717-no-cpio.info.patch
963304-remove-superfluous-declaration-of-program_name
992045-CVE-2021-38185-rewrite-dynamic-string-support
992098-regression-of-orig-fix-for-CVE-2021-38185
992192-Fix-dynamic-string-reallocations.patch
autoreconf.patch
fix.better.handle.device.nodes.cramfs.565474.patch
fix.fatal.exits.mt.576637.patch
fix.mt-erase.manpage.patch
fix.other.bugs.patch
fix.win32-compat.patch
fix.win32.out-pass.mode.579533.patch
fix.win32.undef.stat.patch
revert-CVE-2015-1197-handling.patch
series
$ cat debian/patches/revert-CVE-2015-1197-handling.patch
From: Chris Lamb <lamby@debian.org>
Date: Sat, 1 Feb 2020 13:36:37 +0100
Subject: Fix a regression in handling of CVE-2015-1197 &
--no-absolute-filenames.
See:
* https://bugs.debian.org/946267
* https://bugs.debian.org/946469
This reverts (most of): https://git.savannah.gnu.org/cgit/cpio.git/diff/?id=45b0ee2b407913c533f7ded8d6f8cbeec16ff6ca&id2=3177d660a4c62a6acb538b0f7c54ba423698889a
---
src/copyin.c | 2 --
tests/testsuite | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/copyin.c b/src/copyin.c
index e1350af..e0a092a 100644
--- a/src/copyin.c
+++ b/src/copyin.c
@@ -646,8 +646,6 @@ copyin_link (struct cpio_file_stat *file_hdr, int in_file_des)
link_name = xstrdup (file_hdr->c_tar_linkname);
}
- cpio_safer_name_suffix (link_name, true, !no_abs_paths_flag, false);
-
res = UMASKED_SYMLINK (link_name, file_hdr->c_name,
file_hdr->c_mode);
if (res < 0 && create_dir_flag)
And since Ubuntu is a Debian-based distribution, we checked the stable Debian packages, which also includes the reverted patch.
Solving the case
Our research involving the RCE in Zimbra Collaboration Suite has been like a good crime novel. A series of events that need investigation, interesting characters, with a twist at the end revealing that an unsuspected character was the killer. Reverting vulnerability-related fixes based on suggestions on a mailing list is bad practice. For Zimbra Collaboration instances, only servers where the ‘pax’ package was not installed were affected. But other applications may use cpio on Ubuntu as well. However, we are currently unaware of other attack vectors. Since the vendor has clearly marked CVE-2015-1197 in version 2.13 as fixed, Linux distributions should carefully handle those vulnerability patches—and not just revert them.
Uncover the truth with Flashpoint
New vulnerabilities are disclosed everyday and sometimes, the details you need to remediate them simply aren’t available. That is why it is important to have an experienced vulnerability research team in your corner. Sign up for a free VulnDB trial to get actionable details on over 300,000 vulnerabilities affecting all manners of IT, OT, IoT, and third party libraries and dependencies.