# Unrar Path Traversal Vulnerability affects Zimbra Mail
by simon scannell| June 28, 2022
![Zimbra server being attacked](https://images.seebug.org/1657087083206-w331s)
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](https://www.volexity.com/blog/2022/02/03/operation-emailthief-
active-exploitation-of-zero-day-xss-vulnerability-in-zimbra/), 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,](https://www.rarlab.com/) 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](https://www.rarlab.com/rar_add.htm) and is included with the
binaries of version [6.12](https://www.rarlab.com/download.htm). 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](https://www.rarlab.com/download.htm) 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:
![Zimbra Mail processing](https://images.seebug.org/1657087085738-w331s)
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:
OS| Relative Payload| Absolute Payload
---|---|---
Windows| ..\\..\\..\tmp\shell| C:\tmp\shell
Unix| ../../../tmp/shell| /tmp/shell
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](https://darrenmartyn.ie/2021/10/27/zimbra-
zmslapd-local-root-exploit/).
## 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](https://www.rarlab.com/download.htm), 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](https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P32https://) by configuring Amavis to use 7z instead of unrar to extract incoming RAR attachments.
## Timeline
| Date | Action |
| ---------- | ------------------------------------------------------------ |
| 2022-05-04 | We report the bug in unrar to RarLab. |
| 2022-05-04 | We are already in communication with Zimbra about another issue. We give them a heads up about an upcoming security patch from RarLab and send them a Proof-of-Concept exploit to verify that the issue affects Zimbra |
| 2022-05-04 | RarLab confirms the issue. |
| 2022-05-05 | RarLab sends us a patch for review. We confirm the patch is effective the same day. |
| 2022-05-06 | RarLab releases version 6.12 of the binary on their website. |
| 2022-05-07 | We send a dedicated email to Zimbra regarding this issue and send the Proof-of-Concept exploit again. |
| 2022-05-11 | We notice a flaw in our Proof-of-Concept and send Zimbra more files to help them verify the issue. |
| 2022-05-11 | We notify Debian and Ubuntu package maintainers of the security issue. |
| 2022-05-11 | Zimbra notifies us that they were able to reproduce the vulnerability. |
| 2022-05-20 | Zimbra addresses this issue by configuring Amavis to use 7z instead of unrar to extract incoming RAR attachments. |
| 2022-05-25 | We notify Zimbra of the planned release date for this blog post. |
## 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](https://www.youtube.com/watch?v=V-DdcKADnFk).
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.
## Related Blog Posts
* [Zimbra 8.8.15 - Webmail Takeover via Email](https://blog.sonarsource.com/zimbra-webmail-compromise-via-email/)
* [WordPress 5.0.0 Remote Code Execution](https://blog.sonarsource.com/wordpress-image-remote-code-execution/)
* [Cachet 2.4: Code Execution via Laravel Configuration Injection](https://blog.sonarsource.com/cachet-code-execution-via-laravel-configuration-injection/)
* [RainLoop Webmail - Emails at risk due to Code Flaw](https://blog.sonarsource.com/rainloop-emails-at-risk-due-to-code-flaw/)
暂无评论