I reported a bug that Apple later tracked as CVE-2025-24104. In my original report, I demonstrated how a malicious backup could be used to bypass sandbox restrictions. However, Apple’s initial description stated that this vulnerability could lead to modifications of protected system files. I want to set the record straight: this bug actually allows an attacker to read arbitrary files outside the sandbox.

Timeline

• Found: April 2024
• Reported: October 2024
• Patched: iOS 18.3 beta 1

What I Discovered

When I dug into the issue, I found that the vulnerability stems from a lack of proper symlink validation during the backup restoration process. Specifically, if you craft a backup where the file
/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.configurationprofiles/Library/ConfigurationProfiles/CloudConfigurationDetails.plist
is replaced with a symbolic link, the system ends up reading a file of your choosing—even if it lies outside the sandbox.

How It Works

• The Flaw:
  The mc_mobile_tunnel lockdown service fails to check whether CloudConfigurationDetails.plist is a symlink. If it is, the service follows the link, allowing an attacker to retrieve the content of any restricted file.

• Steps to Reproduce:

  1. Create a Malicious Backup:
     I crafted a backup where CloudConfigurationDetails.plist is a symlink that points to any restricted file.
  2. Restore the Backup:
     I restored this backup on a device and rebooted it.
  3. Exploit the Bug:
     Using a lockdown connection, I sent the GetCloudConfiguration command to the com.apple.mobile.MCInstall service. Instead of getting the expected file content, the service returned the contents of the file my symlink pointed to.

Why It Matters

The ability to read arbitrary files outside the sandbox is a serious issue. It means that sensitive system data, which should remain protected, could be exposed to attackers. This isn’t just a minor bug—it’s a fundamental security flaw in how backups are handled.

My Recommended Fix

To fix this, the backup restoration process needs a more rigorous check:

• Symlink Validation:
  Before reading any file like CloudConfigurationDetails.plist, the service should verify that it’s a regular file and not a symlink. If it is a symlink, the restoration should either reject it or handle it safely.
• Sandbox Enforcement:
  Strengthen sandbox restrictions so that even if a symlink is followed, it cannot point to files outside the intended area.

Patch Details

With the release of iOS 18.3, Apple introduced additional checks in the ManagedConfiguration framework to remove any symlinks found in the ConfigurationProfiles folder. Specifically:

• A new function called MCRemoveFileIfSymlink was added.
• This function is invoked by MCFixHostileSymlinks.
• Whenever a file in the ConfigurationProfiles folder is identified as a symlink, it is immediately deleted.

You can see the bindiff details here:
https://github.com/blacktop/ipsw-diffs/blob/main/18_2_22C152__vs_18_3_22D5034e/DYLIBS/ManagedConfiguration.md

Below is a screenshot of my own diff showing where the new checks were added:

Note on Mitigation Effectiveness

It’s worth mentioning that this new mitigation does not fix the issue 100%. I’ve already found a method to bypass it because Apple didn't implement my recommended fix, but I will keep those details private.

This is my personal account of CVE-2025-24104, emphasizing that Apple’s original description missed the mark. The true risk is the unauthorized reading of files out-of-sandbox, not modifications to system files.

Exploit found by Hichem Maloufi (ifpdz)