Security for OCLP (OpenCore Legacy Patcher)

[Sven G]

Everything that's in /S/L/E is in there because it can't be in /L/E - ie. GPU bundles need to be in /S/L/E because that is hardcoded. Frameworks also have to be on the root volume as well for the same reason.

Thank you for the explanation, and good to know: so, sadly, the optimum of having also a sealed system doesn’t seem to be achievable…

 

[Sven G]

It's been a while so my memory is a bit shoddy on that, I think it is because Ventura+ require a lot more downgrades (including Metal.framework etc) compared to Monterey and as such the advancements that we had in enabling more of SIP had to be rolled back. Monterey really was a simple release, Ventura turned out to be utter hell requiring a new tool (dyld shared cache extractor/dsce because Apple started moving on disk binaries to the cache) plus all kinds of things to be done and thus it took a long time to happen, Sonoma was easier again after the groundwork being done with Ventura. Ventura was so bad the other of the lead devs almost called it quits and thoughts of dropping non-Metal were also being thrown around.

Thank you for the explanation: seems reasonable…

 

[Sven G]

[…] A fellow contributing developer and I have been looking at ways to reenable some security protections for over a year now, and it's been slow going and we don't have anything we can share (and we don't want to make any guarantees). Even still, the likelihood that we can bring things up to the level of security that unpatched Macs have is slim, as there are too many things out of our control.

That’s a very good thing: so, let’s hope that some form of (even small) improvement will be doable, eventually…

 

[Sven G]

@Sven G I think you'd have to fork your own version for that

Slight joke aside - I think we need a separate thread which offers coding advice to developers that are operating at a high level that I have rarely seen. I think that coding and implementation advice (if even necessary) is way premature when we haven't even developed a requirements document. But that again is just the product mgr in me. If we continue that kind of discussion in a thread, we're going to lose the requirements discussion (which may or may not be the intent).

Now that I better understand the motivations behind some choices, it is probably not so necessary to be excessively technical anymore…

 

[Sven G]

… Only one last technical question: if you enable the restricted file system in Ventura and Sonoma (with SIP at 0x801), the window server crashes (and thus the system is essentially unusable, even if it boots successfully); so, in Ventura+, WindowServer now seems to need a completely writable file system: right? And why this? Only to try to understand some things a little better, after having done some very simple experiments (I’m only a power user, or a tech enthusiast)…

 

[Sven G]

[…] I know disabling SIP and AMFI and using 3rd party and unsigned kexts can lead to serious security risk and I grant you that but as we're all well aware, most of the times negligence on the user's part is the reason they get hacked regardless of the computer or the operating systems they're using. […]

This is very important, IMHO: the end user should always adopt a prudent and sensible behaviour, possibly also avoiding to store too sensitive information on the (OCLP’d) Mac.

(Sorry, should have used multiple quotes in one single message, instead of multiple replies.)

 

[cyberdevs]

(Sorry, should have used multiple quotes in one single message, instead of multiple replies.)

It's Ok.

This is very important, IMHO: the end user should always adopt a prudent and sensible behaviour, possibly also avoiding to store too sensitive information on the (OCLP’d) Mac.

Yes I agree, the end user must be aware of the risks and caveats of using macOS on unsupported Macs specially when it comes to security risk.

I do suggest while the developers are working on the documentation since you're the OP you can add the highlights and the most common warnings to the first post so new OCLP users can get a glimpse of what's at risk and how to prepare themselves for protecting their data when using OCLP.

I personally never store any precious data on an old mac using OCLP (or any other methods for that matter) not only because of the security risks (which is the most important reason) but for the sake of the stability, specially after bricking the Mac using OCLP after installing macOS updates once or twice I've learned my lesson (This statement doesn't mean it was OCLP's fault)

So as a wise man once said: "If anything can go wrong, will go wrong." - Murphy's First Law

 

[Sven G]

^^^ I enabled WikiPost, so anyone can make some relevant additions to the first post: of course, needless to say, use this judiciously…

 

[deeveedee]

@Sven G @cyberdevs In my opinion it is premature to summarize risks and make design suggestions. It is the Devs turn to respond. Many of the risks are now public and in some ways more extensive than I thought. That's not bad, just a fact.

In the same way I've been told to review the code to see what's in the analytic reports instead of seeing the report itself, others can review this thread to see the risks in context (much easier than a code review).

Please allow this combination of risks, requests and requirements to mature and develop before summarizing anything. You'll just be rewriting it after making what are probably inaccurate or incomplete thoughts and misleading statements.

Thank you.

 

[Sven G]

^^^ OK, maybe after all it’s not a so good idea to make a WikiPost now: so I disabled it, at least for now. Ordinary posts should be sufficient…

 

[cyberdevs]

In my opinion it is premature to summarize risks and make design suggestions

I didn't mean it to happen right away. What I meant was it can be added to the first post gradually and over time when they are available from the developers and anyone else with enough qualifications.

If any of the mods or the admins decides these post are not related to the topic please feel free to remove them. Thanks.

 

[deeveedee]

I'm capturing a snapshot (below) to prepare for my response. I am waiting patiently for Devs to review more recent content that may influence their statements and responses. No rush, no pressure.

For those who want a summary of the currently known security risks in OCLP, read this thread in its entirety from the beginning. Context is important. It's ok and advisable to ignore the personal jabs.

If you see where my posts are innacurate, untrue or personal attacks, please PM me and allow me the opportunity to correct them. I will freely admit my errors openly and publicly and correct them. I am working hard and to the best of my ability to stick with facts and accurate statements. Thank you. And thank you again, @Sven G , for creating this thread.

Spoiler

The beginning of this thread was filled with a significant amount of subjective snark, and it is hard to respond in an objective manner (this is version 3 of this response, written and edited over multiple days) when reading that. It may seem funny to you, but it hurts the people who work on this out of passion. Being disparaged for not having the capacity to do things as well as Apple does (which, arguably, Apple is not perfect at either) is not fair. It would be nice if everyone could stay focused on technical discussion, as the latter half of this thread has been.

Spoiler: Note about (OCLP) developers, MacRumors, and official statements

The lead developers of OCLP are Mykola (khronokernel) and I. We do not monitor MacRumors; I only look (at a sum total of 5 threads) when I am bored or if I am told to look (which I was for this thread), I post even more rarely, and I don't think Mykola looks at MR at all anymore. So MR is not the best way to get ahold of us.

This generally isn't an issue, but I do want to clarify that Mykola and I are also the only ones who can officially speak for OCLP. Anything official needs to be endorsed by one of us. The viewpoints of contributors are not official viewpoints, and they do not speak for the project.

---

I don't think there's a point in this. For the most part, people using OCLP will either not understand the intricacies of the specific security downgrades required, or just not even read it and gloss over it. Others will completely misinterpret it as OCLP actively hacking your devices, which is obviously not the case. Even still, there won't even be much space in the UI to explain it beyond a sentence or two.

Instead, I think it's better to mention it in the docs - there will be more space for it, and everyone using OCLP will be reading the docs anyway.

This is not feasible. We cannot implement this at the UEFI level (we're not UEFI devs), and implementing this on something like the login screen would require patching a significant chunk of macOS (especially when our goal is to avoid patching as much as possible), for something that a significant amount of people will disable when they first see it anyway.

I don't want to get too deep into the analogy game, but it's not like macOS pesters you to add a password if you didn't set one. Many people would be pissed off if it did.

This would be a niche feature that I don't see being used often (I assume most people want WiFi to work). It's not worth spending development time on (which consists of not only the time it takes to write the code, but also to test it and ensure nothing breaks).

What's sent is always the same, it's just a subset of what's listed in the statistics section of the App section of settings, and is only sent on launch. The specific stuff is detailed here. Crash reporting is also detailed there, although it was disabled as we kept getting too much spam from our GUI framework.

I think a good compromise is documenting what's sent in the docs.

The aim of this wording is to convey that it's possible for nightlies to break your installation/machine as they're not tested - it is not intended to make any comment on security with OCLP. I will clarify it.

Again, not feasible. We can only boot Ventura and above on these machines because we use a cryptex used for Rosetta support on Apple silicon machines. These cryptexes do not make use of AVX2, while normal Intel cryptexes do. RSRs have different contents between Intel and Apple silicon, and only Apple silicon RSRs are shipped with said cryptex.

We don't have a way of emulating AVX2, and even if we could the performance implications would make the Macs slower. We have thought about trying it anyway, but it's a significant task and none of us have any ideas on how to approach it.

It does seem like Apple has shied away from using RSRs recently though, especially since they aren't usable for kernelspace bugs.

This is a fair point - as newer macOS versions have been released, more and more models have been requiring patches that require downgraded security protections, and the docs haven't been updated to reflect that. I will update the docs to clarify this, and we will add a page on security caveats introduced by use of OCLP and legacy hardware in general.


This is not as simple as it sounds. Updating kexts/frameworks that we've downgraded is a much bigger endeavor than most people think it is. There are a few reasons for this:

• Future updates may change/break things - this is why certain kexts/frameworks are pinned to point releases in the middle (ie. 11.3) as this was the latest working version
• If we update something, we now have to test on every single model that makes use of it, and version compatibilities also come into play
• Some of these downgraded kexts/frameworks are patched as well
• Some kexts/frameworks depend on other kexts/frameworks, and those kexts/frameworks could have the same issues

We can't backport security fixes either, Apple doesn't release the source code for frameworks and kexts. This is why pushing out any kind of security update is not simple at all.

Then there's kexts that were dropped that we add back, which we can't do anything about as Apple has simply stopped updating them.

Because of everything mentioned above (security is already compromised to begin with), updating kexts/frameworks has not been a priority for us. We will take a look to see what we can update without breaking things, but it's definitely not going to be quick.

I'm not fully sure about what you're asking for. Do you want security updates released quicker (as a patch version update, as we're using SemVer now) without waiting to group it with more changes? Or are you asking for something else?

---

Ideally, we would like to decrease the attack surface that is introduced with OCLP. However, this takes a lot of time, especially when we need to make sure what we're doing is user-friendly and stands up to everything users do. AMFIPass in itself took months of work (before the beta releases) of isolating what was wrong, trying various approaches in order to work around the problem, testing it to make sure it worked, fixing it because it didn't, and writing the code once it finally worked to implement it into OCLP.

A fellow contributing developer and I have been looking at ways to reenable some security protections for over a year now, and it's been slow going and we don't have anything we can share (and we don't want to make any guarantees). Even still, the likelihood that we can bring things up to the level of security that unpatched Macs have is slim, as there are too many things out of our control.

This thread now has a very specific, well-defined purpose. If we need another OCLP thread where we can contemplate the wonders of software development and have a beer, someone please create that thread and provide the link. I think it's in our best interest to keep this thread focused with minimal clutter.

While some have questioned the use of this medium for this discussion and have questioned the discussion of requests vs 'technical questions', this is exactly what we need: a self-documenting repository of OCLP security issues. None of the content that I posted here is without careful thought. I have no ill-will, malicious intent or hidden agendas, BUT YOU SHOULD NOT TRUST ME OR BLINDLY BELIEVE ME. I AM NOT TRYING TO BE YOUR FRIEND OR TO WIN 'LIKES.'

EDIT: I need to state this with all that it means by its face value and by what it implies and I know this will anger some. I don't know how to say it in a way that does not incite emotional response. It is the only way I know how to say this - If I ask you to TRUST me and BELIEVE me because I'm a nice person and I'm working hard for you, that's when you should start doubting me (and realize that you should never have believed me). I am structuring this thread and my posts to be self-evident and fact-based, so that you don't need to TRUST me, you don't need to BELIEVE me and you don't even need to know me.

 

[deeveedee]

The risk to OCLP-Patched Macs that can't receive Rapid Security Responses

Since I don't want to modify previous posts while the Devs review them, I have an RSR (Rapid Security Response) example that illustrates why RSRs could be so important and why not having them could be a problem. As I noted earlier in this thread, some early Macs patched with OCLP will NOT be able to receive Rapid Security Responses from Apple. Regardless of the frequency of these RSRs (even if only once) and regardless of how Apple has used RSRs in the past (or how some speculate that Apple will use them in the future), Apple is able to release an RSR to address macOS flaws, including security vulnerabilities. See this "Zero-Day" example. If such a security flaw were discovered on an older Mac patched with OCLP and Apple decided to address the flaw with an RSR instead of an incremental macOS release, that Mac would remain vulnerable to the Zero-Day attack until the next macOS release (whenever that is).

Even if the Devs figure out how to deploy RSRs for older OCLP-patched Macs, those Macs would be waiting for an OCLP update, NOT an Apple update. My posts in this thread about Devs being on vacation or unable to immediately respond to bugs and flaws are not snarky jokes - they are the reality of the OCLP user and are real risks that the OCLP user should be permitted to knowingly accept or reject. OCLP is maintained and supported by a small (albeit very capable) team. It is unreasonable to expect this team to sign up to a 5-nines SLA (service level agreement) or to a 24-hour response time.

This is just another example of my request for OCLP transparency - adopters and users need to know that the used car they are driving may not have working airbags in the event of an accident. It is NOT acceptable to bury security risks somewhere in the users manual that sits in the glove box and is never going to be read or in code that requires review by a knowledgable developer.

 

[deeveedee]

OCLP Option to disable Wi-Fi post-install patches

A new thread here for Sonoma-compatible Wi-Fi that does not require OCLP. Details below.

=========================================

Given what we now know to be true about the post-install patches for Sonoma Wi-Fi (derived / extracted from older macOS, not receiving direct updates from Apple and not easily updated via OCLP in the event of a flaw or security issue), it might be very desirable to have a Wi-Fi alternative that does not require OCLP.

This is another example of why OCLP transparency is important and how users should be alerted to risks so that they can make informed choices.

I am still looking for a proven and tested USB Wi-Fi solution that works with Sonoma without any OCLP post-install patches. If such a solution exists, it is very reasonable for OCLP to allow users to disable Wi-Fi post-install patches so that we can use our own Wi-Fi solution without depending on OCLP. If anyone knows of a proven/tested USB Wi-Fi solution for Sonoma, please feel free to nominate your solution here.

EDIT2: A new thread here for Sonoma-compatible Wi-Fi that does not require OCLP. This new thread is currently not a wiki.

EDIT3: I have posted a Sonoma-compatible Wi-Fi solution here that is working very well for me. It does not require OCLP root-patches and does not require any additional drivers or software. It uses the Mac's Ethernet port (assuming the Mac has one). Since I do not want/need OCLP Wi-Fi root patches, I build OCLP using the instructions here.

 

[Sven G]

^^^ OK, I’ll try to add it; but it looks like only the first post of the thread can be made into a WikiPost: should I enable it (specifying that the wiki is only for posting Sonoma USB Wi-Fi solutions), or not…? Otherwise, you can perhaps open a new thread beginning with a ”Sonoma USB Wi-Fi“ WikiPost…

 

[deeveedee]

@Sven G Ok - I'm still learning. I like your idea. I'll start a new thread for Sonoma Wi-Fi without OCLP and figure out how to make it a wiki. Stay tuned for the link (but don't hold your breath - busy). Thank you.

EDIT: A new thread here for Sonoma-compatible Wi-Fi that does not require OCLP. This new thread is currently not a wiki.

EDIT2: I have posted a Sonoma-compatible Wi-Fi solution here that is working very well for me. It does not require OCLP root-patches and does not require any additional drivers or software. It uses the Mac's Ethernet port (assuming the Mac has one). Since I do not want/need OCLP Wi-Fi root patches, I build OCLP using the instructions here.

 

[Sven G]

Edited the title of this thread from OCLP Security to a more descriptive Security for OCLP (OpenCore Legacy Patcher)…

 

[houser]

Three simplistic security question put as simply as possible:
1. Will the use of OCLP on an unsupported Mac in itself enlarge the attack surface?
I would assume that you would still need to have some code delivered to you Mac for any exploit to take place?
Or will any OCLP wi-fi vulnerability also aid for example man-in-the-middle exploits without delivered malware on your drive?

2. Which is the last version combo of OCLP and Mac OS that has non-rooted wifi patches?

3. What should _not_ be discussed here in order to not give aid to malevolent actors?
I suspect these questions may be good examples of stuff that should not be discussed here?

 

[Sven G]

I could be wrong, but Ventura 13.6 doesn’t need any Wi-Fi patches, with the latest OCLP 1.0.1: right (question for the experts)…?

 

[deeveedee]

I could be wrong, but Ventura 13.6 doesn’t need any Wi-Fi patches, with the latest OCLP 1.0.1: right (question for the experts)…?

Root patching requirements are different depending on the Mac model, but I believe that you are correct that no Wi-Fi root patches are required on any Macs before Sonoma. I have only seen and required OCLP Wi-Fi root patches for Sonoma in my limited testing. That is why here (see "frozen in time" discussion), I indicate that users aware of the reduced security caused by Sonoma Wi-Fi root patches may choose to stay with Monterey or Ventura (versions of macOS that are still fully supported by Apple and are still receiving Apple updates).

EDIT: I am still patching Big Sur, Monterey and Ventura with OCLP 0.6.8. There are no Wi-Fi root patches and it works very well. I suspect that I could patch Big Sur, Monterey and Ventura with OCLP 1.x.x, but I haven't found the need or advantage to do so. If OCLP 1.x.x incorporates data security improvements and the requested computer security warnings, then that would be a reason for me to upgrade OCLP on these older versions of macOS.

EDIT2: OCLP lists the patches to be applied in a user-acknowledged prompt prior to applying the root patches, so users should know which patches are being applied. This prompt would be one place where computer security warnings could easily be displayed by OCLP.

EDIT3: @Sven G I have modified the first post here to indicate that Monterey and Ventura are currently Sonoma alternatives that do not require OCLP Wi-Fi root patches. When Monterey is no longer receiving Apple updates, Ventura will still be an alternative to Sonoma (until Ventura no longer receives Apple updates).

 

[deeveedee]

3. What should _not_ be discussed here in order to not give aid to malevolent actors?
I suspect these questions may be good examples of stuff that should not be discussed here?

Obfuscation and hiding are not valid methods of computer security. If we can imagine the vulnerability or there is a hidden "back door," the sophisticated hacker will find it without our help. If the vulnerability remains hidden and we don't discuss it, the hacker may continue to exploit the vulnerability in a way that may be without our knowledge. Sometimes the worst vulnerability is the one where we think no one knows about it (when we may have a false sense of security).

1. Will the use of OCLP on an unsupported Mac in itself enlarge the attack surface?

The attack surface presented by an OCLP-patched Mac depends on the Mac model. OCLP customizes patches depending on the model. This is why I ask to have OCLP security warnings specific to each SMBIOS model (and some warnings will apply to all models). Any Mac that requires OCLP Wi-Fi post-install patches will have a significantly expanded attack surface.

2. Which is the last version combo of OCLP and Mac OS that has non-rooted wifi patches?

See here and here.

 

[houser]

Obfuscation and hiding are not valid methods of computer security.

Many thanks for your comments. I would think there might be limits to specific things that should not be discussed here as I have seen that practiced in various places. That would be beyond my own skillset anyway and for others to consider. Would appreciate comment on my question when you have a sec:
I asked:
I would assume that you would still need to have some code delivered to you Mac for any exploit to take place?
Or will any OCLP wi-fi vulnerability also aid for example man-in-the-middle exploits without delivered malware on your drive?

 

[deeveedee]

I would assume that you would still need to have some code delivered to you Mac for any exploit to take place?
Or will any OCLP wi-fi vulnerability also aid for example man-in-the-middle exploits without delivered malware on your drive?

I think each of us needs to use our own judgment when asking / answering questions in this open forum. So far, I'm pleased with the way this thread is documenting and explaining the OCLP security risks. The use of OCLP or any software should be subject to this same scrutiny and analysis that results in a tradeoff between desired features/capabilities and data security. I think that the only topics that are off-limits here are personal attacks, opinion pieces that are devoid of facts and off-topic posts that can only serve to divert attention from OCLP security risks (which may be the intent of the one posting). Read this.

A vulnerability does not become a problem until someone exploits it, but that doesn't mean the vulnerability is not dangerous. If you use OCLP on your Mac and then you never connect your Mac to a network (e.g., Wi-Fi network) and you never insert a USB thumb drive or never transfer data/apps to/from your Mac in any way, the Mac may be virtually useless, but it will not be a computer security risk.

That may sound like a snarky answer, but it's the way you need to think about this. Once OCLP patches your Mac, it has an expanded attack surface. The risks to you, your data, your identity and your bank accounts depend on how and where you use the OCLP-patched Mac. Discussing the ways in which someone might exploit the vulnerability (man-in-the-middle, malware) is interesting but doesn't really help to lessen the risk (but may help to close the security hole). If I can't provide you with an example for how a vulnerability could be exploited, you should not feel any safer. It just means that I am not smart enough, sophisticated enough or clever enough to think of one.

EDIT: Hackers are very good at playing "The long game." I provided references here, including the movie "Lucky Number Slevin." I am not joking or being snarky with any of my suggested references and encourage all to review them. It is very likely that a simple review of code/architecture would not reveal a potential hack, because the hack may require many steps in order to exploit the vulnerability. The Stuxnet story is a very good real example. Think "playing chess."

EDIT: @houser Here is a real-world example that I think will illustrate the idea of data/computer security vulnerabilities without known exploits. For those who process credit cards, they may need to submit servers, websites and solutions for PCI compliance testing and certification (search for PCI compliance to learn more). It is very common for a PCI compliance / vulnerability scan to identify a vulnerability which exists but for which there are currently no known exploits. If such a vulnerability is identified (one without a known exploit), it is possible to still fail the PCI compliance test. In the world of computer security, it is never safe to assume that one is safe if one cannot think of an exploit.

 

[houser]

If you use OCLP on your Mac and then you never connect your Mac to a network (e.g., Wi-Fi network) and you never insert a USB thumb drive or never transfer data/apps to/from your Mac in any way, the Mac may be virtually useless, but it will not be a computer security risk.

So your answer to my question about delivery of malware in a roundabout way, is that you do still need some code delivered to your drive in order to exploit any attack surface that OCLP may create?
With wi-fi other parts of the attack surface might be at play that in turn might not require delivery of malware to your drive? Something like that to get started?

 

[deeveedee]

@houser My answer is that it doesn't matter whether I know or can provide the steps for an exploit. This is a good discussion and could be very interesting, but I think it's one that needs a new thread (where I'd be happy to participate).

In the world of computer security, it is never safe to assume that one is safe if one cannot think of an exploit.

EDIT: ... and if one were to create a thread titled "Known OCLP Security Exploits" and this thread remains empty, that should not make anyone feel safe when using their OCLP-patched Mac. It just means that the hacker who has developed the exploit doesn't want anyone to know.