Exploiting CVE-2024-32002 via Xcode 15.4

TL;DR: Update Xcode to latest version 16.0. If you are still using Xcode 15.4 pay attention on what you clone. Make sure the sources are trusted if you don’t want to let remote attackers execute code in your machine.

Introduction

About five months ago, a remote code execution via git clone operation was discovered and a few PoCs were published on GitHub (eg: safebuffer poc, amalmurali47 poc). CVE-2024-32002 was associated to this vulnerability.

A detailed root cause analysis is out of the scope of this article. If you want to have a full comprehensive description of it, I recommend reading this post. To sum it up, I would say that playing with git submodules and symbolic links in a proper way could permit to overwrite git hooks files inside .git/hooks/ directory when cloning a project in case-insensitive filesystems. Git hooks are shell scripts executed before or after specific git operation. In particular, a repository is checked out to the main branch as one final step of the clone operation: overwriting post-checkout script, the attacker can execute arbitrary commands.

After reading that CVE’s writeup, I got curious to understand if also Xcode is affected in some way by this flaw. Xcode ships inside its bundle a modified (?) version of git, and launching % /Applications/Xcode.app/Contents/Developer/usr/bin/git --version form a shell git version 2.39.3 (Apple Git-146) is printed.

Strategy

The goal is to undestand if cloning a repository via Xcode GUI triggers a remote code execution as per CVE-2024-32002.

First of all, it is necessary to craft a (minimal) Xcode project so that after the clone, it is automatically opened in Xcode GUI. As far as I know, a minimal Xcode project that is correctly and automatically opened with no errors is made up of a <project_name>.xcodeproj directory with the file project.pbxproj inside of it. This file is a critical component of Xcode projects, defining metadata about the project, including the configuration settings, file references, build settings, and various other properties that define the project structure and its contents.

In particular, inside project.pbxproj is possible to define dependencies as Swift packages through the objects XCRemoteSwiftPackageReference and XCSwiftPackageProductDependency, hosted behind a remote repositoryURL. This feature is part of SPM (Swift Package Manager), enabling developers to include libraries or frameworks that are not part of their project.

...

/* Begin XCRemoteSwiftPackageReference section */
		8C46D71C2B5887AC002899DB /* XCRemoteSwiftPackageReference "dep" */ = {
			isa = XCRemoteSwiftPackageReference;
			repositoryURL = "https://github.com/p1tsi/dep.git";
			requirement = {
				branch = main;
				kind = branch;
			};
		};
/* End XCRemoteSwiftPackageReference section */

/* Begin XCSwiftPackageProductDependency section */
		8C46D7242B588973002899DB /* libdep */ = {
			isa = XCSwiftPackageProductDependency;
			package = 8C46D71C2B5887AC002899DB /* XCRemoteSwiftPackageReference "dep" */;
			productName = libdep;
		};
/* End XCSwiftPackageProductDependency section */

...

A Swift package must contain the Package.swift file, which basically is the manifest file of the package defining its structure, dependencies, and how it integrates with other packages.

To sum up, Xcode clones a main project and opens it; then the SPM fetches (read “git clone”, again) the Swift package defined as dependency along with all its submodules, if present.

If this last dependecy package is properly crafted (as git modules and submodules defined in CVE-2024-32002’s writeup) and git is vulnerable, it could be possible to run arbitrary commands defined inside the post-checkout hook script of the dependency package.

Exploit

A precondition is that the git global config core.symlinks should be set to true, but it looks like this is the case in Xcode context.

Actually the exploit is the same as safebuffer’s PoC with a small number of changes.

The PoC for Xcode is here.

The steps to reproduce the issue are:

1. Create three GitHub repositories: “fin”, “dep” and “poc”.
2. Execute the script with % ./exploit.sh.
3. Open Xcode (v15.4) and clone “poc”.

Unfortunately, at that time when I was playing with this PoC, I did not record any video or gather evidence of the successful outcome of the attack, so if you want to be sure it works, try it yourself :).

Remediation

On 16 Sept 2024, Apple released Xcode 16.0 and the git binary inside Xcode’s bundle is updated to git version 2.39.5 (Apple Git-154).

Trying to reproduce the PoC with this new version of git results in the error in the following image.

After having a very quick look of the new git binary, I found out that, between other changes, the function validate_submodule_path was added (according to this commit).

Conclusion

With this small research, I wanted to proof if a well known consumer product as Xcode was vulnerable to CVE-2024-32002 and demonstrate how to weaponize a GitHub Xcode project to gain RCE.

Xcode contains in its application bundle an (Apple customized?) version of git vulnerable in the same way of the one installed via homebrew.

So if you are still using Xcode 15.4, I recommend paying attention on what you clone and always check what dependencies the project defines.

Extra mile

Perhaps this is a trivial advice and it does not need this addition, but when cloning Xcode projects from the Internet and from untrusted sources, I also recommend paying attention to “Build Scripts”. As Xcode lets developers execute custom shell scripts when building projects, it could be possible to execute every shell command within this build phase (Are you also thinking about curl + run commands? Surely everyone already knows that files downloaded from the Internet with curl are not labelled with ‘com.apple.quarantine’ extended attribute…).