Fun with Fuzzers: How I Discovered Three Vulnerabilities (Part 3 of 3)

This is the third part in a three-part series that chronicles how I discovered three vulnerabilities over the course of a day. If you haven’t already, you can go back and read the first two installments: Part 1 and Part 2.

Vulnerability Analysis

In Part 1 of this series, I discussed fuzzing and how it helped me to discover CVE-2019-13032 and CVE-2019-13453. In my investigation of CVE-2019-13453, I examined the code in FlightCrew that processes EPUB (ZIP) files from end to end. I noticed that FlightCrew was extracting the EPUB files and writing them to disk. I also noticed that no validation of the extracted file paths was being performed. I began to suspect that FlightCrew might be vulnerable to Zip Slip.

Zip Slip is a type of directory traversal vulnerability discovered by the Snyk security team and publicly disclosed on June 5, 2018. It can occur when a specially crafted archive file is extracted. In Snyk’s own words:

Zip Slip is a form of directory traversal that can be exploited by extracting files from an archive. The premise of the directory traversal vulnerability is that an attacker can gain access to parts of the file system outside of the target folder in which they should reside. The attacker can then overwrite executable files and either invoke them remotely or wait for the system or user to call them, thus achieving remote command execution on the victim’s machine. The vulnerability can also cause damage by overwriting configuration files or other sensitive resources, and can be exploited on both client (user) machines and servers.
https://snyk.io/research/zip-slip-vulnerability

I’ve omitted the vulnerable ZIP extraction code for the sake of brevity, but you can find the affected version here: https://github.com/Sigil-Ebook/flightcrew/blob/0.9.2/src/zipios/src/zipextraction.cpp.

To confirm my suspicion, I downloaded the Zip Slip sample archive and passed it to the FlightCrew CLI.

The newly created /tmp/evil.txt file confirms that FlightCrew is, indeed, vulnerable to Zip Slip.

Security Impact

In order to exploit this vulnerability, a local user must open a maliciously crafted EPUB file. That EPUB file can overwrite the user’s configuration files or other files, which might grant the attacker remote access or cause malicious code to be executed. This attack does not allow for privilege escalation and is, therefore, limited by the permissions and capabilities of the user.

Remediation

As of July 15, 2019, Ubuntu users have access to a patched version of FlightCrew 0.7.2. Other FlightCrew users can apply the following patches and rebuild:

Disclosure Timeline

While analyzing CVE-2019-13453, a Zip Slip vulnerability in FlightCrew is discovered.

Upstream developers are notified via a secure channel. A CRD of July 22, 2019 is proposed.

Upstream developers respond, requesting that the issue be made public on GitHub.

Upstream developers patch the vulnerability.

MITRE assigns CVE-2019-13241 to this vulnerability.

Summary & Lessons Learned

Of the three vulnerabilities discussed in this series, this was the most exciting and impactful vulnerability that I found. Whereas AFL did most of the work in finding the previous two vulnerabilities, I discovered this third one through an analysis of the code. While the previous two vulnerabilities allow for denial of service attacks, this one may allow for remote code execution.

Overall, my first foray into vulnerability research was a fun, challenging, and rewarding experience. Here are a few key takeaways:

Code used for validation should make no assumptions.

The sole purpose of code that performs validation is to accept and safely process malformed input. Any assumption that the input will conform to any expectation, no matter how small, can lead to a bug or security vulnerability. When reviewing code that performs validation, be on the lookout for any assumptions.

Fuzz your applications prior to each release.

Fuzzers should not be just a tool for security research; they should be used during software development and testing to find bugs before software is released. If you employ automated testing or continuous integration, adding a fuzzer to your pipeline is a great way to enforce this policy.

Fuzzing an application can be a shortcut to fuzzing a library.

Not all software is easy to fuzz. For example, libraries are not programs that you run, but programs that are used by other programs. One way to fuzz a library is to write a small piece of code called a “harness” that accepts input and calls the library’s functions. If you find an application that utilizes the library, fuzzing it can be quicker than writing a harness.

Mike Salvatore's Blog

A blog about cybersecurity