macOS Unpatched Transparency, Consent and Control (TCC) Vulnerabilities

Yiğit Can Yılmaz
5 min readNov 10, 2024

--

Cover

In this article, I would like to discuss unpatched security vulnerabilities present in the macOS operating system. All the security issues you see here have been reported to the Apple Product Security team, but for various reasons, Apple Product Security has declined to fix them. Frankly, I do not agree with Apple’s decisions regarding these security issues. Although I have raised objections on this matter, I have not been able to achieve any results. My opinions on this issue remain unchanged.

1- Media Library:

With macOS 15, the media library located within the “~/Music/Music” folder is directly protected by TCC (Transparency, Consent, and Control). When an application attempts to access this directory, the user is prompted with a TCC request.

TCC prompt for media library

However, the media library within the “~/Music/Music” folder is created by the Music app only after the Music app is launched for the first time.

An attacker or a malicious application could create a DMG file on a macOS device where the user has not previously launched the Music app, mount it to the “~/Music/Music” folder, and set up a fake media library without triggering any TCC prompt. The attacker could then wait for the user to launch the Music app, causing the app to save data within this DMG file. This way, the attacker could capture the user’s media library.

This issue is so similar with CVE-2024–27871.

PoC:

diskutil image create blank --format RAW --size 1GB --volumeName "Music" /tmp/music.dmg
mkdir ~/Music/Music
hdiutil attach -nobrowse -mountpoint ~/Music/Music /tmp/music.dmg
read -p "> Open Music app and close it, then press Enter"
hdiutil detach -force ~/Music/Music
hdiutil attach -nobrowse /tmp/music.dmg
cd "/Volumes/Music"
zip -r ~/Desktop/musicLibrary.zip *
cd ..
hdiutil detach -force /Volumes/Music

Poc video:

Proof of concept for Media Library TCC

Apple Product Security team’s response:

“Thanks for your report. We are not tracking this as a security issue and have forwarded your report to the appropriate team to investigate as a potential enhancement request. We recommend reporting this via https://feedbackassistant.apple.com, since we do not provide status updates for non-security issues.

If you are able to reproduce this after launching Music for the first time, we’d be interested in investigating that scenario.”

However, this situation does not apply to the photo library. With macOS 15, the Photo Booth photo library is protected by TCC. Like the Music app, Photo Booth does not create its own photo library until the app is launched. However, if an application other than Photo Booth attempts to create a photo library or mount a DMG file on a macOS device where Photo Booth has not yet been launched, a TCC prompt is triggered. In this way, TCC protects the user from potential manipulation or unauthorized access to user data.

TCC behaviour for Photo Booth Library

2- Media Library #2:

By holding down the Option button when opening the TV, Music, or Photos app on macOS, you can set the location of the library that will be used as the default.

Choose default library for Photos prompt

TCC continues to protect it even if you specify a different library. For example, if you create another photo library within the “~/Pictures” folder and set it as the default Photos Library, TCC also protects that library.

However, if you create a different media library within the “~/Music/Music” folder for the Music app and set it as the default, unfortunately, TCC does not protect it.

PoC video:

Proof of concept for Media Library

Apple Product Security team’s response:

“After reviewing your report, we did not see any security or privacy concerns that need to be addressed. The default music library is already protected by TCC.

If in the future you are able to reproduce this issue using the default library, please let us know.”

3- iOS/iPadOS Backups:

On macOS, backups from iOS/iPadOS devices are stored by default in the “~/Library/Application Support/MobileSync/Backup” folder. There are multiple ways to back up iOS/iPadOS devices, including:

  • Apple Configurator
  • cfgutil (the command-line tool for Apple Configurator)
  • Finder

Even if you run these tools with root privileges, they still save backups by default to the “~/Library/Application Support/MobileSync/Backup” folder. This ensures that an application cannot access the user’s backups directly; for the application to access them, it must have full disk access permissions.

On macOS, there is a command-line application called AppleMobileBackup (/Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/AppleMobileDeviceHelper.app/Contents/Resources/AppleMobileBackup). This tool allows you to back up and restore data from iOS/iPadOS devices. When you run this tool with root privileges to create a backup, it saves the backup by default to the directory “/private/var/root/Library/Application Support/MobileSync/Backup/”, which is not protected by TCC (Transparency, Consent, and Control). This poses a security risk, as an application running with root privileges can back up an iOS/iPadOS device connected to the macOS device and access the backed-up data.

PoC:

sudo /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/AppleMobileDeviceHelper.app/Contents/Resources/AppleMobileBackup -b --target YOUR_DEVICE_UDID_NUMBER

You can find the UDID number of the connected device with this command:

system_profiler SPUSBDataType | sed -n -E -e '/(iPhone|iPad)/,/Serial/s/ *Serial Number: *(.+)/\1/p'

PoC video:

Apple Product Security team’s response:

“Thank you again for reporting this issue to us.

Since reproducing this issue requires a non-standard configuration, we don’t see any security implications at this time. The backups were created within the root user’s directory, leaving it unprotected. If you can reproduce this issue without the custom configuration, please provide an updated proof-of-concept, and we will investigate further.

For an extra layer of protection, we always recommend that users encrypt their local backups to help prevent unauthorized access.”

I conveyed that I did not perform a special configuration for them, but only ran the command-line tool with root privileges. I explained that, in this way, an application running with root privileges could access these data by taking a backup from an iOS/iPadOS device and that the backups are protected by TCC (Transparency, Consent, and Control) by default normally. I also detailed that even if an application has root privileges, it cannot bypass TCC. I sent them the sysdiagnose. However, the result did not change.

--

--