This post includes the details of the first vulnerability I have ever reported to Apple. It was fixed on macOS Sonoma 14.7 and macOS Sequoia 15.0 as CVE-2024-40801
.
A vulnerability in macOS allowed a sandboxed app to bypass TCC (Transparency, Consent and Control) protections and access sensitive user data without requiring user permission. By leveraging the container-migration.plist
feature, a sandboxed app could request the migration of TCC-protected files (like Safari history, Mail database, or user documents) to its app container, effectively bypassing TCC and giving the app full access to these files. There are multiple examples included in this repository demonstrating the exploit.
Below is the full report as submitted to Apple. You can also check the GitHub repository that includes the example projects to reproduce the vulnerability.
A sandboxed Mac app can exploit the container-migration.plist
feature to get access to TCC-protected files without any user permission prompt.
For example, you can request the Safari history file or Mail database to be migrated by the App Sandbox to the app container, and it will happily do it. Once the files are in the app container, the app has full control to read and exfiltrate this data.
You can use the attached project to reproduce the exploit (check the demo video at Extra/Videos/ContainerMigrationExploit.mp4
):
Scripts/ContainerMigrationExploitReset.sh
in a Terminal with Full Disk Access. This script will:
Exploit
app (if it exists).Expected
app that shows the proper expected behavior when accessing the protected files.my-secret.txt
.History.db
) and Mail recent searches plist (recentSearches.plist
). Both of these files are protected by TCC, and reading them requires Full Disk Access as they contain very sensitive data like contacts and the browsing history. The first time the script runs, the restore will fail, but you can ignore it.Projects/ContainerMigrationExploit.xcodeproj
.Expected
scheme: this is an un-sandboxed app that tries to read directly the files that the exploit app will steal. As you see, it triggers the expected TCC permission prompt when reading the my-secret.txt
file in the Documents folder, and it also cannot access the Safari history database nor the Mail recent searches plist as they are stored in protected directories.Exploit
scheme: this sandboxed app is able to read the three files without any issue as they have been migrated by the App Sandbox into the app container.As demonstrated by the Expected
scheme, the app should not be able to access any of the data in the protected directories without user permissions and/or Full Disk Access. Even worse, a sandboxed app is able to get more access to sensitive files than an un-sandboxed app using this technique.
The Exploit
app can access sensitive files protected by TCC without any user permission. This same technique can be used to exfiltrate the following data from a fully sandboxed app:
This new version of the project includes a new Mail-app-specific example project in Projects/MailContactsExploit.xcodeproj
that demonstrates how you can use this exploit to dump all your Mail contact addresses without any TCC prompt from a fully sandboxed app (demo video at Extra/Videos/MailContactsExploit.mp4
).
This same exploit can also be used for a denial-of-service / ransomware attack as the original files (in this example, the Mail database) are deleted by the App Sandbox migration from the original location and are now in full control of the attacker app.
Some details about how the exploit seems to work under-the-hood:
secinitd
daemon.secinitd
reads the container-migration.plist
file in the app bundle.secinitd
has the kTCCServiceSystemPolicyAllFiles
value in the com.apple.private.tcc.allow
entitlement, it can access any protected directory and moves the protected files into the app container.You can check the related Endpoint Security events from eslogger
in the directory Data/EndpointSecurity/
.
This final version of the project includes a demonstration that this same exploit can also be used to exfiltrate both Calendar & Contacts databases, even though their paths are symlinked inside the app container, by leveraging a custom destination in the container-migration.plist
file:
<dict>
<key>Move</key>
<array>
<array>
<string>${Home}/Library/Calendars/Calendar.sqlitedb</string>
<string>${Home}/Calendar.sqlitedb</string>
</array>
</array>
</dict>
You can check a Calendar-specific example project at Projects/CalendarExploit.xcodeproj
and a demo video at Extra/Videos/CalendarExploit.mp4
.
This is a recap of some posts I published on Threads during the past week.
The OpenAI ChatGPT for Mac app stored user conversations in plain text in a non-protected location, making them accessible to any running app or malware. After public disclosure, OpenAI released an update encrypting the conversations but did not implement sandboxing.
The OpenAI ChatGPT app on macOS is not sandboxed and stored all conversations in plain text in a non-protected location:
~/Library/Application Support/com.openai.chat/conversations-{uuid}/
This approach is somewhat typical for non-sandboxed apps on macOS, but a high-profile chat app like ChatGPT should be more careful with user data. For example, Apple started blocking access to user private data 6 years ago with the introduction of macOS 10.14 Mojave. Before that, any non-sandboxed app could access any user file. With macOS Mojave, Apple began requiring explicit user permission to access sensitive files like the Calendar, Contacts, Mail or Messages databases. Later, Apple extended this requirement to the Desktop and Documents directories, and with macOS 14 Sonoma, any file stored by a sandboxed third-party app in its sandbox container is automatically protected. This protection prevents malware or untrusted apps from exfiltrating user data without triggering a permission prompt like this:
Unfortunately, OpenAI opted out of sandboxing the ChatGPT app on macOS and stored conversations in plain text in a non-protected location, disabling all these built-in defenses. This meant that any running app, process, or malware could read all your ChatGPT conversations without any permission prompt.
Here you can see how easily any other app could access any ChatGPT conversation without any permission prompt:
You can check the source code of this demo app, ChatGPTStealer, on GitHub.
Initially, I reported this issue to OpenAI through their security bug reporting program in BugCrowd, but they marked the report as “Not Applicable” as “in-order for an attacker to leverage this, they would need physical access to the victim’s device.”
As I disagreed with that consideration, I decided to post this issue publicly on Threads & Mastodon to raise awareness and encourage OpenAI to fix this issue and hopefully sandbox the ChatGPT app on macOS. These posts gained attention and were eventually covered by The Verge, Ars Technica, 9to5Mac, and others.
Following these publications, OpenAI finally acknowledged the issue and released ChatGPT 1.2024.171 for Mac, which now encrypts the conversations. The conversations are now stored in a new location:
~/Library/Application Support/com.openai.chat/conversations-v2-{uuid}/
These files are now encrypted with a key named com.openai.chat.conversations_v2_cache
stored securely in the macOS Keychain and the old plain-text conversations are removed after upgrading to the new version. However, the app is still not sandboxed, so the conversations are still stored in a non-protected location, but now at least they are encrypted so other apps can’t read them without user-granted access to the Keychain key.
Interestingly, macOS Sequoia will introduce protections for Group Containers, so non-sandboxed apps like ChatGPT could improve their security by moving sensitive data to a Group Container directory. This way, any other process or app trying to access the data would be blocked by the system, and a permission prompt would be presented to the user.
You can use the MakePass AI service in the MakePass app with the Ultra subscription to create Apple Wallet passes instantly using an input photo or document of a ticket or card:
MakePass is a mighty Apple Wallet pass editor, with it you can create and customize a myriad of passes with complex layouts including images, barcodes, colors and text fields. Now it includes a new service called MakePass AI available with the MakePass Ultra subscription that allows you to create Apple Wallet passes instantly using an input photo or document of a ticket or card. It can even design the pass using a pass description.
MakePass AI uses technologies like text recognition, barcode recognition and Artificial Intelligence powered by OpenAI ChatGPT models to compose Apple Wallet passes from photos or documents of tickets and cards.
Here you can see some examples of passes generated automatically with MakePass AI from some input image or document:
Input | Pass |
---|---|
MakePass is available on the App Store for iPhone, iPad and Mac.
This archive of WWDC sessions is meant to extend the current collection of videos available on Apple Developer website with all the sessions prior to WWDC 2017 that are not available there but continue to be hosted by Apple servers.