TL;DR overview
- Sonar discovered a pre-authentication remote code execution vulnerability in Zimbra that exploits a zero-day flaw in the unrar utility used to process email attachments.
- An attacker can send a specially crafted RAR attachment to any Zimbra mailbox, and the server automatically processes it with the vulnerable unrar binary—no user interaction required.
- The pre-auth nature of the attack means any Zimbra server exposed to the internet is vulnerable, regardless of the targeted user's security awareness or email hygiene.
- Zimbra released an emergency patch; the vulnerability demonstrates how third-party binary dependencies in email servers create critical attack surfaces that traditional application security testing may miss.
At Sonar, we are studying real-world vulnerabilities to improve our code analyzers, and to help the open-source community to secure their projects. To uncover and understand complex vulnerabilities in high-profile applications, our researchers need to take the perspective of real-world attackers. By sharing our findings from this perspective, we also aim to provide useful insights and learnings to the community.
Zimbra is an enterprise-ready email solution used by over 200,000 businesses, government and financial institutions. Zimbra instances recently became a target of a 0-day attack campaign, likely conducted by a state actor who targeted European government and media instances.
The fact that a 0-day vulnerability was used to steal emails from individual user accounts shows how valuable a compromised email account is to an attacker and how disastrous the impact of such vulnerabilities is on an organization. Classified documents could be stolen, passwords reset, and members of an organization impersonated to compromise more accounts.
In this blog post, we present how our research team approached Zimbra by taking on the perspective of an APT group. As a result, we discovered a 0-day vulnerability in the unrar utility, a 3rd party tool used in Zimbra. The vulnerability ultimately allows a remote attacker to execute arbitrary code on a vulnerable Zimbra instance without requiring any prior authentication or knowledge about it.
Software and versions affected
In this section we go into detail about which versions of unrar are affected. Although this blog post focuses on Zimbra to demonstrate the impact of this bug, any software relying on an unpatched version of unrar to extract untrusted archives is affected.
What can an attacker do?
We identified a File Write vulnerability(CVE-2022-30333) in the unrar binary developed by RarLab, the same company that develops WinRAR.
An attacker is able to create files outside of the target extraction directory when an application or victim user extracts an untrusted archive. If they can write to a known location, they are likely to be able to leverage it in a way leading to the execution of arbitrary commands on the system.
In the case of Zimbra, successful exploitation gives an attacker access to every single email sent and received on a compromised email server. They can silently backdoor login functionalities and steal the credentials of an organization's users. With this access, it is likely that they can escalate their access to even more sensitive, internal services of an organization. The only requirement for this attack is that unrar is installed on the server, which is expected as it is required for RAR archive virus-scanning and spam-checking.
Am I affected?
The official security patch by RarLab is contained in the UnRar source code version 6.1.7 and is included with the binaries of version 6.12. Any previous version may be vulnerable. Only the Unix binaries (excluding Android) are affected by this vulnerability. WinRAR is free of this bug.
The vulnerable and patched version can differ depending on the Linux distribution you use and from which repository the binaries were downloaded. If you want to make sure that you use a version that includes the security patch, we recommend downloading it directly from RarLab's website.
There are multiple, popular implementations of unrar. Only the implementations relying on RarLab's code are affected.
How is this related to Zimbra?
Zimbra is not at fault for this unrar vulnerability, but its exploitation is only possible due to the broad permissions associated with the impacted service. For instance, an unauthenticated attacker can write a JSP shell into the web directory while this is an unrelated service.
A Zimbra instance is affected if unrar is installed, which is expected as it is required for spam checking and virus scanning of RAR archives. Due to the way unrar is invoked, it is also expected that RarLab's implementation is installed, which is the vulnerable one.
Technical Details
In the following sections, we go into detail about the attack surface we audited prior to the discovery of the unrar bug, its root cause, and how an unauthenticated attacker could exploit it to gain code execution on the Zimbra instance.
Background - Spam checking and the file format problem
As Zimbra is an all-in-one solution, it comes with pre-configured software for sending and receiving emails. It also tries to detect spam and scan for viruses when an email is received.
The following graphic shows some of the software involved when a Zimbra instance receives an email:
Incoming emails are processed by Postfix via SMTP (1). Postfix then passes the email to Amavisd (2). Amavis parses the incoming email, recursively extracts attachments such as ZIP and RAR files, and then sends all files to Spam Checker Spamassassin and anti-virus ClamAV (3). If the email is deemed clean, it is passed to Zimbra's code (4).
All of these third-party services support the parsing and processing of many file formats. To do so, they rely on even more external software components. For example, when Amavis parses an incoming email and detects a RAR archive as an attachment, it uses the unrar utility to extract it to a temporary directory.
In the next section, we will break down a path traversal vulnerability that can be triggered when a malicious RAR archive is extracted by Amavisd.
CVE-2022-30333 - File Write vulnerability in unrar
Background - unrar extraction and security assumptions
A typical invocation of unrar on the command-line could look like the following:
unrar x archive.rar /tmp/extract
This command will extract all files in the archive archive.rar into the directory /tmp/extract.
An application or user invoking this command expects that files are only written to the /tmp/extract directory. Software such as Amavis relies on this assumption to ensure that all files can be safely deleted after processing them. This safety net is implemented by unrar and is enabled by default.
Symbolic link extraction logic
One of the challenges unrar faces is that maliciously crafted RAR archives can contain symbolic links. An attacker could extract a symbolic link that points outside of the extraction directory and then dereference it with a second file.
Preventing symbolic link attacks turns out to be complicated, as RAR archives can be both created and extracted on Windows and Unix, which have significant differences when it comes to filesystem path handling. Symbolic links can also be relative and absolute. Here are examples of malicious symbolic links for Unix and Windows file systems:
In order to prevent symbolic link attacks on Unix systems, unrar forbids any symbolic links with an absolute path by checking if the first character is a forward slash (/).
Validating relative symbolic links is done by the IsRelativeSymLinkSafe() function, a snippet of which is shown here:
extinfo.cpp
127 bool Dot2=TargetName[0]=='.' && TargetName[1]=='.' &&
128 (IsPathDiv(TargetName[2]) || TargetName[2]==0) &&
129 (Pos==0 || IsPathDiv(*(TargetName-1)));
130 if (Dot2)
131 // …As can be seen, this function checks if the symbolic link target contains two dots followed by a path divider (../ on Unix and ..\ on Windows). When an attempt at path traversal is detected, the symbolic link is deemed unsafe.
Bypassing the symbolic link validation
We mentioned checking if the symbolic link contains path traversal sequences (../) works. However, this check is negated by a common vulnerability pattern where untrusted data is modified after it has been validated.
Once the symbolic link has been validated, it is normalized by unrar. We mentioned previously that a RAR archive could have been created on a Windows or Unix system and that these operating systems handle file paths significantly.
To ensure that a RAR archive created on Windows can be extracted on a Unix system, backslashes (\) are converted to forward slashes (/).
The following snippet shows how this happens when the RAR archive entry representing the symbolic link has the type of FSREDIR_WINSYMLINK, which is the case if the archive was created on a Windows system:
ulinks.cpp
93 if (hd->RedirType==FSREDIR_WINSYMLINK || hd->RedirType==FSREDIR_JUNCTION)
94 {
95 // …
101 DosSlashToUnix(Target,Target,ASIZE(Target));
102 }The DosSlashToUnix() function simply converts all backslashes to forward slashes. Attackers can exploit this behavior as this operation is breaking previous assumptions of the validation step.
Let's assume an attacker crafted a RAR archive that contains a symbolic link of type FSREDIR_WINSYMLINK with the target ..\..\..\tmp/shell. As the archive is extracted on a Unix system, the symbolic link target is deemed safe as no ../ sequence is detected.
However, due to the normalization of DosSlashToUnix(), the final symbolic link target is ../../../tmp/shell. By exploiting this behavior, an attacker can write a file anywhere on the target filesystem.
As always with our research, we chose not to release any exploitation code. We could successfully exploit these bugs on our internal research instance and believe that threat actors will be able to reproduce it if they didn't already. We strongly recommend upgrading your systems to use the latest versions of unrar.
Exploitation in Zimbra
As mentioned previously, when an email with a RAR archive attachment is received, it is automatically extracted for analysis by Amavis via unrar. In Zimbra, most services, including the Amavis server, run as the zimbra user.
As a consequence, the file write primitive allows creating and overwriting files in other services' working directories. An attacker can achieve RCE impact via various means. We mentioned for example, that an attacker could write a JSP shell into a web directory. Luckily, most Zimbra instances have their services distributed across multiple servers and thus this path of exploitation is not possible on most installations. However, we have reported multiple different paths of exploitation that work on distributed installations. For this reason we recommend upgrading unrar immediately, even if your web server and mail server are not on the same physical machine.
Getting root access after exploitation
When an attacker has successfully exploited the unrar vulnerability on a Zimbra instance, they can execute arbitrary system commands as the zimbra user. At the time of writing, a publicly known privilege escalation from zimbra to root exists, along with exploit code. The vulnerability was discovered by Darren Martyn.
Patch
RarLab patched the issue by ensuring that the path validated is the same that is used to create the symlink. The patch is included in binary version 6.12, which can be downloaded from RarLab's website. We urge anyone to make sure they are using a patched version of unrar. If administrators prefer to install unrar via a package manager, they should check if their repository contains the patched version as versions may differ depending on the Linux distribution they use.
We notified Zimbra of this bug so that they could issue a warning to their users and patch their cloud instances. We also mentioned the fact that most services run as the zimbra user made exploitation of this issue possible. Zimbra has addressed this issue by configuring Amavis to use 7z instead of unrar to extract incoming RAR attachments.
Timeline
Summary
In this blog post we broke down the technical details of CVE-2022-30333, a path traversal vulnerability in unrar. We demonstrated how this vulnerability lead to pre-authenticated RCE on Zimbra and how such vulnerabilities can be exploited in detail.
This vulnerability follows a common vulnerability pattern, where a modification of user input after it has been validated leads to a bypass of security checks. We have given a talk on this topic before, which you can watch here.
We would like to thank the RarLab developers for their very fast and professional handling of this issue.
We would also like to thank Zimbra’s security team for taking this issue seriously and warning their customers to help prevent exploitation.