Jamf Threat Labs identifies macOS Archive Utility vulnerability

Introduction

Jamf Threat Labs recently discovered a new macOS vulnerability in Archive Utility that could lead to the execution of an unsigned and unnotarized application without displaying security prompts to the user, by using a specially crafted archive. We reported our findings to Apple on May 31, 2022, and in macOS Monterey 12.5 Apple patched the vulnerability, assigning it CVE-2022-32910.

Research led by Ferdous Saljooki, Detections Developer II, Jamf.

Initial discovery

Earlier this year, Jamf Threat Labs identified a vulnerability in the Safari Web Browser that could bypass Gatekeeper checks by leveraging a crafted ZIP archive (CVE-2022-22616). At a low level, this vulnerability existed within the parsing of the Bill of Materials (BoM) when an application was placed within a zip file using a syntax like the following:

 zip -r test.app/Contents test.zip

After reporting the issue to Apple, we began to research other archiving features that might suffer from similar issues.

This brought us to the testing of the macOS Archive Utility, where we discovered that creating an Apple Archive with a similar command will also result in bypassing Gatekeeper and all security checks upon execution.

 aa archive -d test.app/Contents -o test.app.aar

Despite the fact that this command looks somewhat similar to the ZIP command that could previously be used to abuse CVE-2022-22616, this vulnerability is different in that it doesn’t involve the BoM at all. Instead, it is a vulnerability within the operation of Archive Utility which handles ZIP files (and many other archives) by default, when they are double-clicked.

Archive Utility

Archives are commonly used to compress and store files making it easier to share multiple files across devices. Apple provides a built-in archiving tool called Archive Utility which allows users to create and extract supported archives. Users can also create archives by right-clicking files or folders within Finder and selecting Compress. Archive Utility has a minimal user interface and is located at:

 /System/Library/CoreServices/Applications/Archive Utility.app

Archive Utility is capable of extracting various archive formats such as 7-ZIP, ZIP, TAR, CPIO, GZIP and Apple Archive. Double-clicking a supported archive by default will cause Archive Utility to process the unpacking of the archive.

Apple has its own archive format referred to as Apple Archive. This is Apple’s proprietary format which allows for multithreaded lossless compression of directories, files and data, including file attributes. We initially did all of our research using these archive files, however, the vulnerability is not specific to Apple Archives as we’ll explain later.

Apple provides a command-line utility titled aa for manipulating this format. Using the aa utility we can create an archive with the following command,

 aa archive -d dirName -o myPictures.aar 

Apple Archive uses the .aar file extension which is recognized within Finder. Such a file is natively supported by Archive Utility for decompression when double-clicked.

When an archive is downloaded from the internet, it will hold an extended attribute titled com.apple.quarantine. This extended attribute will indicate to the macOS that the file has been downloaded from a remote source and should be checked before it is allowed to execute. When Archive Utility extracts an archive, it applies the quarantine attribute to all of the extracted items. This ensures that the quarantine attribute is propagated accordingly and that any opened executables will be checked by Gatekeeper.

Discovery of the vulnerability

For a demonstration of how archives are handled by Archive Utility, we will create some archives containing pictures using the aa command. Take a look at the following directory structure:

We can create an Apple Archive that holds the photos folder shown above using the following command:

 aa archive -d images -o myPictures.aar 

This archives all of the files and folders contained within the images directory and outputs an archive named myPictures.aar. It’s worth noting the aa utility intentionally archives everything under the specified folder. So, if this archive were to be downloaded and unarchived, we would see the following:

Here’s where things get interesting. Let’s create another archive using the same command, except this time, we will add an additional file named 4.png to the root of the images directory.

Next, we download the archive again and open with Archive Utility:

When Archive Utility unarchives this file, we see two noticeable differences:

1. This unzipping resulted in a new folder that matches the name of our archive file minus the extension (“myPictures”). This folder was created by Archive Utility rather than us.
2. The newly created “myPictures” folder does not have the com.apple.quarantine extended attribute on it, but the files within it do.

So, why is this new folder missing the quarantine attribute? When extracting an archive containing two or more files or folders in its root directory, Archive Utility will create a new folder based on the specified archive name. In our example, the root directory of our archive contained a folder named photos and a file named 4.png. When our myPictures.aar file was unpacked, Archive Utility created a folder named myPictures containing our extracted files. Presumably, this feature exists to prevent many files from being extracted to the current directory making it inconvenient to move or delete.

A number of processes are involved in the unpacking of an archive including Archive Utility, AUHelperService and ArchiveService. Using Apple’s Endpoint Security to monitor file usage, we can determine that the ArchiveService process writes the extracted contents to a temporary directory located at the following path:

 /private/var/folders/{2-random-characters}/{31-random-characters}/T/com.apple.fileprovider.ArchiveService/TemporaryItems/NSIRD_ArchiveService_{6-random-characters} 

Archive Utility contains a function titled _propagateQuarantineInformation. The ArchiveService process will ensure the quarantine attribute is propagated to all of the extracted contents before it is moved to the target location (typically, the user's Downloads folder). It invokes a low-level function titled _qtn_file_apply_to_path in libquarantine.dylib which applies the quarantine attribute to the unarchived files located in the temporary directory NSIRD_ArchiveService_XXXXXX.

However, ArchiveService failed to apply the quarantine attribute to the NSIRD_ArchiveService_XXXXXX folder itself, only applying the quarantine attributes to the extracted contents within it. We will see why this is important when the temporary directory is renamed.

A function titled _decompressMoveCopyResults is invoked by AUHelperService to move the extracted contents from the temporary directory to the target destination. In the disassembly code below, we highlight some of the steps that occur when the extracted archive is moved to its final destination.

1. The function retrieves the path to our extracted archive located in a temporary folder.
2. The function retrieves the path to our downloaded archive.
3. The file name of our archive is extracted from the path.
4. The file extension of our archive is removed.
5. The non-quarantined temporary folder holding our unarchived files (NSIRD_ArchiveService_OTbAIm) is renamed to its destination folder (myPictures).

As a result, our myPictures folder does not have a quarantine attribute applied to it.

Exploiting the vulnerability

Now that we have a better understanding of the vulnerability, we will demonstrate how it can be abused to bypass Gatekeeper.

In the image above, we see that everything below the renamed directory (myPictures) receives the quarantine attribute, as expected. Simply dropping an executable within this folder will not result in any success. However, as we learned from CVE-2022-22616 — when it comes to application bundles — Gatekeeper only cares if the app directory itself has a quarantine attribute set and disregards recursive files within the app bundle. Therefore, we can bypass Gatekeeper by ensuring that our non-quarantined folder (myPictures) is an application.

As mentioned, the folder name containing our unarchived files is controlled by the user because Archive Utility creates this folder based on the archive name without the extension. Therefore, we can name our archive something like test.app.aar so that when it is unarchived, it will have a folder name titled test.app. Within that app will be an expected application bundle holding the executable.

Conditions for exploitation:

1. The archive name must include an .app extension (i.e., test.app.aar).
2. There should be two or more files or folders in the root of the target directory being archived (i.e.,test.app/folder1 and test.app/folder2). This causes the auto-renaming of the temporary directory as described in the vulnerability section of this blog.
3. Only the files and folders within the app should be archived, excluding the test.app directory.

Using the aa utility we can craft an Apple Archive for any application with the following command:

 aa archive -d test.app -o test.app.aar

When a user downloads and launches such an archive, it will be opened by Archive Utility with the following layout:

As we can see, the application does not have the quarantine attribute on it, and therefore, will bypass all Gatekeeper checks allowing an unnotarized and/or unsigned binary to execute.

Although our testing was done with Apple Archives, the same bypass can be achieved with other archive formats such as ZIP archives, in which case the ZIP file could be created while within the app directory.

 cd test.app zip -r test.app.zip .

Apple patched the vulnerability by updating the _propagateQuarantineInformation function with an additional call to _qtn_file_apply_to_path. The temporary folder NSIRD_ArchiveService_XXXXXX now has a quarantine attribute applied to it before it is renamed.

Conclusion

As we continue to see attackers interested in bypassing the security features of macOS, Jamf Threat Labs remains vigilant in detecting Mac threats and vulnerabilities and reporting them to Apple upon discovery. Apple patched this vulnerability in macOS Monterey 12.5 quickly after we reported it. Using Jamf Protect behavioral-based detections we continue to monitor for any abuse of this vulnerability in the wild while providing best-of-breed Mac endpoint protection.

*All images: Jamf Threat Labs