Security for OCLP (OpenCore Legacy Patcher)

[oclp-user]

That’s also why personally I’m a big supporter of enabling SIP as much as possible: as I’ve said many times, with OCLP’d Monterey on a Metal-capable Mac, you could optionally enable SIP fully and leave only the SSV (signed/sealed system volume) disabled (0x800); but that changed in Ventura and Sonoma (0x803 still mandatory: otherwise, with increased SIP, either the window server will crash or the system won’t boot): so, it would be interesting if the devs researched middle/long-term possibilities to enable SIP further also in the two latest macOSes - as they also said themselves in a release note some time ago (that statement was subsequently removed, so it’s unclear if they still pursue this goal)…

(BTW, AMFIPass was a great achievement, which previously seemed almost impossible to reach.)

I want to add that Apple claims the SSV (signed system volume) is necessary for FileVault security in macOS11+:

In macOS 11, equivalent at-rest protection for system content is provided by the SSV, and therefore the system volume no longer needs to be encrypted. [...]

If the user chooses to disable the SSV, the system at rest becomes vulnerable to tampering, and this tampering could enable an attacker to extract encrypted user data when the system next starts up. Therefore the system won’t permit the user to disable the SSV if FileVault is enabled. Protection while at rest must be enabled or disabled for both volumes in a consistent manner.

source: Apple Platform Security guide, SSV and FileVault section (https://support.apple.com/guide/security/signed-system-volume-security-secd698747c9/web)

see also this GitHub issue for OCLP with a very good explanation here:

FileVault on root-patched systems · Issue #457 · dortania/OpenCore-Legacy-Patcher

Machine Model MacBook5,1 Application Version Latest Release Application Variant CLI (Command Line Interface) What versions of macOS are you seeing the problem on? macOS 11, Big Sur Where does this ...

github.com

(basically an attacker could change the system files to enable your password to be stolen next time you login with FileVault) - interestingly the lead developer of OCLP answered that "Unfortunately you cannot [disable SSV] without disabling APFS snapshots and therefore the mechanism to update the OS through system preferences" - which would seem to mean SSV is not disabled?

---

@erikkfi I wholeheartedly agree that OCLP is a valuable project that is extending the life of old, unsupported Macs (and keeping them out of the landfill). I'm a long-time OCLP user, supporter and donator. The challenge I have with OCLP messaging/documentation is that it misleads by stating that your OCLP-patched Mac is just as secure as a Mac that is still fully supported by Apple (the documentation actually says "For many machines, you're just as secure as a supported Mac." when there are no OCLP-patched, unsupported machines that are as secure as a real Mac).

Based on the Developer comments in this thread, it seems that OCLP started as a small hobby (the donation page specifically stated that OCLP is a hobby project until the "hobby" wording was removed in a commit) and the Devs indicated that they did not anticipate the extent of the adoption or the magnitude of the project.

I understand why Devs would not want to highlight the security limitations of an OCLP-patched Mac (it would curtail adoption and donations), but the Devs have a responsibility to be honest in the documentation in the same way that dhinakg was honest in this thread: an OCLP-patched Mac can never be as secure as a fully supported Mac.

At the very least, OCLP should provide a security alert in documentation and during application of post-install patches and "building and installing Open Core" similar to the following:

By using OCLP, you understand that your unsupported Mac will not receive Apple Rapid Security Responses, your APFS seal is broken to permit installation of uncertified root patches and SIP has been partially disabled. These security downgrades may expose you to computer security vulnerabilities that may not be present when using a Mac that is still fully supported by Apple.

I also agree that there should be a warning for users of OCLP who may not know the security risks involved, as I was not aware of the risks and thought this was just as good of a way to keep a secure OS as going the official Apple route, as there were a lot of articles on Ars Technica mentioning OCLP as a viable way to keep older Macs going and I don't ever remember security issues being mentioned (although there is at least one mention of it in an article I recently rechecked).
Only after I decided to search for more info specifically related to OCLP security before installing did I come across this very informative thread.

This is a very simple message to add to the software and on the download page and I support it:

By using OCLP, you understand that your unsupported Mac will not receive Apple Rapid Security Responses, your APFS seal is broken to permit installation of uncertified root patches and SIP has been partially disabled. These security downgrades may expose you to computer security vulnerabilities that may not be present when using a Mac that is still fully supported by Apple.

(and to add the FileVault security risk to the message as well)

 

[oclp-user]

there is also the issue of the firmware not being updated with OCLP, which should also be included in a warning.

Spoiler: It can be updated manually however, see here:

All hardware still supported with Big Sur but dropped from Monterey support will get Apple software and firmware updates until late summer 2023. To apply those (valuable and often necessary firmware) updates you need to install and update Big Sur on your system. All those firmware upgrades are bundled into the macOS Big Sur updates, exclusively.

The most easy way to achieve this is having an APFS container (aka volume) in parallel with your new Monterey installation. No user data needs to be copied in there. Just boot Big Sur when you get an Big Sur update notification and apply all updates.

You may drop (delete) this basic Big Sur installation after Apple stopped delivering new updates. You will not get new firmware releases.

Another method to update the firmware has been described on this site. It requires some system admin technical skills.

source: the lead OCLP developer (https://forums.macrumors.com/threads/macos-12-monterey-on-unsupported-macs-thread.2299557/ - Spoiler: About (new) Apple firmware updates section)

 

[dimme]

Great info here. I am curious for an older MacBook Pro which would be more secure, Running OCLP or Linux Mint. They are both open source and seem to be published by volunteers. I am asking from a security point of view, not which is a better OS.

 

[deeveedee]

Great info here. I am curious for an older MacBook Pro which would be more secure, Running OCLP or Linux Mint. They are both open source and seem to be published by volunteers. I am asking from a security point of view, not which is a better OS.

If anyone answers your question by stating their choice after reviewing the information (or lack of information) that you provided, it's going to be their opinion and will ultimately still be your decision to make.

In order for you or anyone to answer your question, you need to determine the potential impact on your MBP use cases by OCLP's partially disabled SIP, broken APFS seal and injection of uncertified root patches, loss of support for Apple's Rapid Security Responses and, if you are installing Sonoma, root-injection of an older, uncertified Wi-Fi framework extracted from Ventura and modified for Sonoma (a framework which will only be updated if OCLP Devs update it, since no Sonoma Wi-Fi framework updates will be provided by Apple for your MBP).

If Ventura satisfies your requirements, then you can minimize potential vulnerabilities by staying with Ventura for now (since Ventura's Wi-Fi framework is still fully supported by Apple).

Without a security assessment performed by a reputable, certified third party, even after you consider your use cases and the potential vulnerabilities, your decision and anyone's opinion will still be a guess.

 

[bogdanw]

Great info here. I am curious for an older MacBook Pro which would be more secure, Running OCLP or Linux Mint. They are both open source and seem to be published by volunteers. I am asking from a security point of view, not which is a better OS.

Ubuntu

OCLP is not entirely open-source. As far as I know, the code for the AMFIPass kext in not public.
“Implement AMFIPass system
Removes need for disabling Library Validation and AMFI outright on all applicable systems”
https://github.com/dortania/OpenCore-Legacy-Patcher/blob/main/CHANGELOG.md
The AMFIPass-v1.4.0-RELEASE.zip version https://github.com/dortania/OpenCor...Kexts/Acidanthera/AMFIPass-v1.4.0-RELEASE.zip
is signed with an Untrusted certificate.


Linux Mint is based on Ubuntu and third-party modifications might introduce additional vulnerabilities.
The Ubuntu Security Guide https://ubuntu.com/security/certifications/docs/usg
What is System Hardening? Essential Checklists from OS to Applications https://ubuntu.com/blog/what-is-system-hardening-definition-and-best-practices

 

[oclp-user]

Great info here. I am curious for an older MacBook Pro which would be more secure, Running OCLP or Linux Mint. They are both open source and seem to be published by volunteers. I am asking from a security point of view, not which is a better OS.

another thing to keep in mind is how supported is your hardware with macOS Monterey, Ventura, or Sonoma. For example, if your hardware is fully supported in Monterey, but Apple only officially supports your Mac up to Big Sur, installing Monterey with OCLP you wouldn't have to disable any other security settings (i.e. the Security/SIP Settings section will be all unchecked and set to 0x0) - so you still get full SIP, SSV (Signed System Volume), and FileVault.
To do this you have to download the latest version of OCLP for the macOS release that you want to install:

• macOS 12 Monterey > OCLP 0.4.11 (Monterey info thread)
• macOS 13 Ventura > OCLP 0.6.8 (Ventura info thread)
• macOS 14 Sonoma > currently OCLP 1.3.0 (will likely be updated - check here) (Sonoma info thread)

When you install that version of OCLP, the OCLP settings will be automatically adjusted to the correct Security/SIP levels for your current Mac (check in OCLP Settings > Security/SIP Settings to see what security settings you will end up with)


more info/source, from the macOS 12 Monterey info thread - Spoiler: About (new) OCLP updates section:

New OCLP target new macOS versions. For example releases from 0.6.2 onwards in particular made some severe changes for some Macs (disabled AMFI, again) which will disable functionality on Big Sur and Monterey just to allow the use of the latest Ventura releases. Especially Kepler and IvyBridge 2012 Macs are hit by this.

There is absolutely no use and no need to install and use this new OCLP releases unless you have a double boot installation with Ventura or the change log explicitly mentions your Mac model and a special development only available with new OCLP version, e.g the support for iMac9,1 with metal AMD MXM cards or if you are using a non metal pre 2012 Mac.

The best version for AMD metal will be 0.4.11, the best version for Kepler metal 0.5.0, users of non metal (if there are still brave ones left) can used the latest and greatest.

 

[deeveedee]

If you want to know why Apple updates for Sonoma Wi-Fi framework are important (and why you may be at risk if you're using Sonoma Wi-Fi patched with OCLP), this may be interesting reading for you. Chinese hackers claim to have cracked Apple AirDrop.

Many users of OCLP don't realize that when they use OCLP to "patch" Sonoma on their unsupported Mac, OCLP injects an older Wi-Fi framework extracted from Ventura (the Sonoma legacy Wi-Fi framework has been removed by Apple and must be restored by OCLP in order to support legacy Broadcom Wi-Fi). After OCLP patches Sonoma Wi-Fi, Wi-Fi security updates for Sonoma will only be applied if OCLP Devs provide them (Apple will not update your Sonoma Wi-Fi framework when it has been patched with OCLP).

Dhinakg informed us here that updating the Sonoma Wi-Fi framework on unsupported Macs is NOT trivial and "updating kexts/frameworks has not been a priority for us."

If you want Apple Wi-Fi Framework updates on your OCLP-patched, unsupported Mac and Ventura still satisfies your requirements, you may wish to stay with Ventura for now.

EDIT: It is important to understand that even if OCLP Devs are able to extract a newer, updated Wi-Fi Framework from Ventura and they are able to include that updated framework in a future OCLP release, there is no way to determine whether the OCLP update is secure. Without testing and certification by a reputable, accredited verification service (which is costly and unlikely for OCLP), anyone's opinion about the safety and security of OCLP is a guess.

 

[Mark9599]

[/spoiler]

For those who don't understand the purpose of the warnings, think of them this way:
Assume you're not really knowledgeable about automobiles. Your friend has just spent years of effort and much of her own funds to restore an automobile and she offers the automobile to you for free. The offer of the fully-restored, brandnew-looking used automobile gives you the choice between buying a new car or accepting your friend's free gift. Because of the date it was manufactured, the automobile does not have airbags and antilock brakes. It would be nice if your friend warned you about these missing safety features, so that you could make an informed decision between the used car and a new car. It would also be nice to have an occasional reminder about the brakes and air bags, so that you remember the reduced safety in critical situations.

And if you don't know the "friend" very well (and even if you do), it is perfectly acceptable to ask her why she is giving you a free car and if it is possible to add the airbags and anti-lock brakes.

I don't much about any tech at all, but why doesn't Apple just offer support to macs for longer than the standard 5-7 years? The ironic thing to me is that although macs seem like they could easily last an average of 8-10 years for the average user, they become unusable long before that. I don't see why a 10 year old macbook can't still be running the latest Mac OS. What good is longevity if you can't use the device?

 

[Wheel_D]

I don't much about any tech at all, but why doesn't Apple just offer support to macs for longer than the standard 5-7 years? The ironic thing to me is that although macs seem like they could easily last an average of 8-10 years for the average user, they become unusable long before that. I don't see why a 10 year old macbook can't still be running the latest Mac OS. What good is longevity if you can't use the device?

As I understand it, Apple’s policy is to support its major products for 5-7 years after they were last officially available for sale.

 

[dumastudetto]

Excellent read this thread. Bottom line, if you value security and privacy you should be buying new hardware that is stilll in software support with Apple.

Once Apple stops supporting intel in the next year or two, this project will have nowhere else to go.

 

[Wheel_D]

Once Apple stops supporting intel in the next year or two, this project will have nowhere else to go.

Here’s hoping for a pivot to support for Apple silicon, whether from the OCLP team or otherwise. No doubt Asahi Linux is a worthwhile effort, but it would be good to have a viable alternative to Linux.

 

[dumastudetto]

Here’s hoping for a pivot to support for Apple silicon, whether from the OCLP team or otherwise. No doubt Asahi Linux is a worthwhile effort, but it would be good to have a viable alternative to Linux.

It won’t be technically possible to pivot that support. As with iOS, watchOS, tvOS, iPadOS, etc. once support ends, you can’t upgrade via third party workarounds. The firmware for macOS Apple Silicon hardware has similar lockdowns as all those other device types.

 

[Wheel_D]

It won’t be technically possible to pivot that support. As with iOS, watchOS, tvOS, iPadOS, etc. once support ends, you can’t upgrade via third party workarounds. The firmware for macOS Apple Silicon hardware has similar lockdowns as all those other device types.

No doubt. Still, considering that Asahi Linux is already here, I wouldn’t be surprised to see additional options become available.

 

[deeveedee]

This OCLP security discussion has included partially disabled SIP, broken APFS seal, injection of previous-generation Legacy Wi-Fi root patches and the lack of any security warning messages, but I don't believe there has been any discussion of OCLP's use of Open Core "SecureBootModel" (forgive me if we have discussed and I just forgot).

In order for OCLP to perform its magic that allows us to run macOS on unsupported Macs, OCLP sets Open Core's "SecureBootModel" to Disabled. Read more here.

 

[deeveedee]

I suspect that most users won't understand what they are sacrificing by disabling Open Core's SecureBootModel. If you're interested, read this. Open Core can make an Intel-based Mac very secure when SecureBootModel is enabled (but SecureBootModel must be disabled for Open Core Legacy Patcher to allow unsupported Macs to run newer versions of macOS with post-install root patches).

EDIT: Note this interesting statement from the article: 'An attacker who takes over OSX will usually have a hard time gaining persistence due to SIP, but if they discover the computer is a Hackintosh, they can just use OpenCore as a conduit for boot-persistance.' OCLP also requires us to partially disable SIP. Users of genuine Macs, welcome to the world of Hackintosh.

 

[deeveedee]

While I've been focused on the need for transparency about OCLP security deficiencies, it would be wrong of me to ignore a security feature of OCLP (and of Open Core). As @Sven G noted here, OCLP includes a 'vaulting' option that protects the Open Core EFI from tampering:

OCLP > Settings > General:

When enabled, this prevents unauthorized tampering with files in the Open Core EFI. Read more about this here. This should be enabled (my opinion).

Note that users of Open Core without OCLP can use the Open Core > Utilities > Create Vault (in the downloaded Open Core package) to vault their own custom OC EFI.

 

[bogdanw]

EDIT: Note this interesting statement from the article: 'An attacker who takes over OSX will usually have a hard time gaining persistence due to SIP,

That is false.
See KnockKnock, the linked paper "Methods of Malware Persistence on OS X" and BlockBlock https://objective-see.org/tools.html and
"Demystifying macOS's Background Task Management" - Patrick Wardle & Chris Lopez"

 

[deeveedee]

@bogdanw I'll look into this. Your statement "That is false" isn't helpful. Is it false that an attacker will usually have a hard time gaining persistence?" Is it false that an attacker can gain persistence? If we run KnockKnock on a Mac patched with OCLP, does it flag the rooted Wi-Fi framework?

It would be helpful if you explained your statement and why you think the video you attached is relevant. Thank you.

 

[bogdanw]

@bogdanw I'll look into this. Your statement "That is false" isn't helpful. Is it false that an attacker will usually have a hard time gaining persistence?" Is it false that an attacker can gain persistence? If we run KnockKnock on a Mac patched with OCLP, does it flag the rooted Wi-Fi framework?

It would be helpful if you explained your statement and why you think the video you attached is relevant. Thank you.

Persistence can be gained regardless of SIP.

 

[deeveedee]

Persistence can be gained regardless of SIP.

Very good. Re-read the quote you flagged as false. What part of "An attacker who takes over OSX will usually have a hard time gaining persistence due to SIP" says that persistence can't be gained with SIP?

EDIT: The "Methods of Malware Persistence on OS X" paper you referenced is good. It is clear from the paper that Apple has implemented multiple measures to thwart persistence. SIP is only one of them, but since it is partially disabled by OCLP, it becomes a nice academic discussion.

 

[bogdanw]

Very good. Re-read the quote you flagged as false. What part of "An attacker who takes over OSX will usually have a hard time gaining persistence due to SIP" says that persistence can't be gained with SIP?

EDIT: The "Methods of Malware Persistence on OS X" paper you referenced is good. It is clear from the paper that Apple has implemented multiple measures to thwart persistence. SIP is only one of them, but since it is partially disabled by OCLP, it becomes a nice academic discussion.

SIP has nothing to do with preventing persistence.
The person that made that claim doesn’t understand macOS basics, like LaunchAgents and Launch Daemons. https://support.apple.com/guide/terminal/apdc6c1077b-5d5d-4d35-9c19-60f2397b2369/mac
With non-admin rights, you can write in ~/Library/LaunchAgents with SIP enabled.
With admin rights, you can write in /Library/LaunchAgents and /Library/LaunchDaemons with SIP enabled.

OCLP includes a 'vaulting' option that protects the Open Core EFI from tampering:
When enabled, this prevents unauthorized tampering with files in the Open Core EFI. Read more about this here.

That is just security theater.
You need admin rights to mount the EFI partition. If an attacker has admin rights, it can modify all it’s contents, regardless of the “vaulting”.

 

[deeveedee]

@bogdanw I sense that you're smart enough and knowledgeable enough to know that security is multilayered. By themselves, none of the measures is sufficient. But feel free to continue to identify the limitations of each by itself.

EDIT: I hope we agree that a Mac with a sealed APFS volume, fully-enabled SIP, SecureBoot enabled, frameworks signed by Apple and still receiving Apple framework updates is more secure than a Mac where these measures have been defeated (as they are by OCLP). If you're trying to convince me that an OCLP-patched Mac is less secure than a Mac that is still fully-supported by Apple, you've convinced me.

 

[basslik]

Got a question about the WiFi fix in OCLP 1.4.2.

Why does it say I have a weak security (WPA).

My setting is WPA2 in the Mac tab settings, although my router does not have WPA3 Personal (AES)

Never mind, I found my answer, thanks.

 

[dimme]

I have a 2013 MBP that works perfectly, it is not my main machine so I do not do online banking or shopping on it. I was thinking of setting up Sonoma with OCLP and using it for homebrew, and other experimentation/learning. I will not connect to my Apple ID account. With those parameters I am think I should be fine. Am I wrong?

 

[deeveedee]

@dimme The purpose of this thread is to inform OCLP users about the multiple Apple security measures that OCLP must defeat/disable in order to install macOS on unsupported Macs. Apple has wisely implemented multiple layers of security, but OCLP has had to defeat some of these important measures (as documented in this thread). Ideally, those defeated / disabled security measures would be clearly stated in OCLP documentation and warnings, but they are not (if they have been documented in OCLP documentation or warnings, someone please tell me). It is not the intent of this thread to discourage use of OCLP and it is not the intent of this thread to criticize the developers or the software - far from it. What the OCLP devs have achieved is amazing.

Having said that, it would be unwise for this thread to advise individual users, since only you can determine your risk tolerance and only you can assess risks based on your use cases. For example, if you're only using your Mac at home and you are confident in your home security measures (including Wi-Fi security, Firewall), your Mac has a degree of protection that extends beyond itself. If you connect your laptop to public Wi-Fi, that exposes you to security issues that are out of your control.

Without offering advice, if one is not using their Mac for anything that potentially exposes private credentials (even credentials for something like Facebook which can be used as single-sign-on for other applications / sites), and one is not storing sensitive data on their Mac, the risk assessment should be simple.