Unrar Path Traversal Vulnerability affects Zimbra Mail

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, some of which are explained here to help administrators harden themselves against these attacks.

Writing a JSP shell to the web directory

The easiest exploitation path is to create a JSP shell in the web directory, which is a known path (/opt/zimbra/jetty_base/webapps/zimbra/public/). As Jetty runs with the zimbra user as well, the directory is writable.

Using a file-based command injection

When notifying Zimbra about this vulnerability, we provided a Proof-of-Concept that creates a malicious JSP script as mentioned before. They told us that large companies usually distribute the Zimbra services across multiple servers and that it is unlikely that the webmail service runs on the same server as the mail server that extracts the malicious RAR archive. Furthermore, the webmail service is not always exposed to the Internet, as it does not need to be.

To get around this limitation, attackers could exploit a cronjob that runs once a day to process log files.

The following snippet shows how a list of log files is parsed and then the name of each log file is embedded into a system command without sanitization:

zm-core-utils/src/libexec/client_usage_report.py

 31 # Get the list of log files to read
 32 lscmdfmt = 'ls /opt/zimbra/log/access_log* | tail -%d | head -%d'
 33 if numlogfiles > numdays:
 34     lscmd = lscmdfmt % (numdays + 1, numdays)
 35 else:
 36     lscmd = lscmdfmt % (numdays, numlogfiles - 1)
 37 p = subprocess.Popen(lscmd, shell=True, stdout=subprocess.PIPE)
 38
 39 resultmap = {}
 40
 41 for file in p.stdout.readlines():
 42     file = file.rstrip()
 43     subprocess.call('echo Reading %s ..' % file, shell=True)

As the log directory is owned by the zimbra user, they could create a log file called access_log$(date) to call the command date next time the cron job will be triggered.

Creating an SSH key

By default, the zimbra user has an /etc/passwd entry and has a login shell. Thus, the zimbra user can be SSH’d into. By creating an authorized_keys file with an attacker-controlled SSH key, an attacker can get a shell.

The following shows the default passwd entry for the zimbra user:

/etc/passwd

zimbra:x:997:998::/opt/zimbra:/bin/bash

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. At the time of writing, no official patch is available for Zimbra users to harden permissions on instances.

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.

Related Blog Posts

• Zimbra 8.8.15 – Webmail Takeover via Email
• WordPress 5.0.0 Remote Code Execution
• Cachet 2.4: Code Execution via Laravel Configuration Injection
• RainLoop Webmail – Emails at risk due to Code Flaw