Is it possible to patch ZombieLoad Vulnerability on 10.14.4 without updating to 10.14.5?
Thank you,
Greg.
Thank you,
Greg.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
ZombieLoad Vulnerability 10.14.4
- Thread starter Gregnyrfan
- Start date
- Sort by reaction score
Well, sort of but not really. There's probably a way to disable all speculative execution and multi-execution models, which would effectively render the vulnerability fixed, but in terms of a patch, not really. 10.14.5 is the patch as mentioned. But 2 things; One it's not a trivial exploit to run, and 2, it takes a really long time to run with high CPU utilisation as it runs and requires local code execution privileges, so you'd likely notice and be able to shut it down before it could extract anything at all. It could take hours to extract a single character.
Why hesitant to update to 10.14.5 if you want security patches though?
Yeah there are far more interesting vulnerabilities that were fixed in 10.14.5 - don't let the media hype for speculative execution bugs fool you.
For example:
CVE-2019-8635 - AMD's graphics API for Metal could be exploited by a game (probably connected to the network these days) that allows attackers to execute code with system privileges.
CVE-2019-8590 - Apple's Application Firewall could be exploited to execute code with kernel privileges. This is probably a local attack vector too, but it's high severity and likely would be invaluable to an attacker utilizing it as the final stage of a ransomeware attack chain.
CVE-2019-8592 - Arbitrary code execution by playing a malicious audio file. You could view a website that has this malicious audio file embedded, and then the attacker executes code on your system. Combine that with the aforementioned vulnerability and your Mac is totally pwned.
These are a small sample of vulnerabilities patched in 10.14.5 that are way more serious than Zombieload.
https://support.apple.com/en-us/HT210119
For example:
CVE-2019-8635 - AMD's graphics API for Metal could be exploited by a game (probably connected to the network these days) that allows attackers to execute code with system privileges.
CVE-2019-8590 - Apple's Application Firewall could be exploited to execute code with kernel privileges. This is probably a local attack vector too, but it's high severity and likely would be invaluable to an attacker utilizing it as the final stage of a ransomeware attack chain.
CVE-2019-8592 - Arbitrary code execution by playing a malicious audio file. You could view a website that has this malicious audio file embedded, and then the attacker executes code on your system. Combine that with the aforementioned vulnerability and your Mac is totally pwned.
These are a small sample of vulnerabilities patched in 10.14.5 that are way more serious than Zombieload.
https://support.apple.com/en-us/HT210119
Apple does not say how much of the "mitigation" for the "Microarchitectural Data Sampling (MDS)" is done via code in the BootROM vs. macOS on the disk. The BootROM will be updated in 10.14.5 for Macs which can officially run Mojave. One of the NVRAM parameters Apple says you should change for full mitigation (SMTDisable) didn't have any effect on my 2012 Mini before I updated with the recent High Sierra security patch (Currently, Apple looks like it updates the BootROM's for all of the currently supported OS's at the same time.). But after the BootROM update, I can run the OS update prior to current update and the NVRAM parameter works. So I suspect the same is true of other Macs. So it is possible to run the update on a clone external disk or the internal disk and revert and you'll get the BootROM update - but as I mentioned before, Apple doesn't say how much of the mitigation is contained in the BootROM. For most users, I don't suggest this as a recommended action (it's a bit of work and it's not entirely risk-free) - I would agree with the sentiments of the other posters.
It is also possible to update firmware (BootROM and more) without actually installing the OS. See this paper for more details:
https://duo.com/assets/ebooks/Duo-Labs-The-Apple-of-Your-EFI.pdf
I've done this successfully in the past. As far as I'm aware, it doesn't prevent runtime issues (like MDS and the like), but more cold boot or warm boot attacks. Once you're in the OS EFI won't help you much
You are generally speaking correct. There are certain exploits the firmware version could protect you against, even without OS-level protection, like Thunderstrike, but in most cases you're entirely right that it's mainly a pre-boot protection and the OS should still be patched separately.
Sierra is still getting security updates and the earliest MBP that can officially run Sierra is the mid-2010 MBP so I presume if you have it or a later MBP with Sierra or a later OS, you can get the updates. You should check your BootROM BIOS before and after to see if it's updated.
It was more a matter of "Don't just update your EFI. Do the OS update too."
If you want to be sure don't lock the windows while leaving the front door wide open
My 2010 13" MBP got a firmware update with the latest 10.13.6 security patch, but that CPU doesn't support Hyper-Threading and won't get a microcode update from Intel, so I don't know what the update changed.
This is a good point. Apple's page on what's addressed in it's current round of security updates is at:
https://support.apple.com/en-us/HT210119
If you search for "10.12.6", you can see what is affected for Sierra (thus, what will get updated on a 2010 MBP). I don't see anything in the Sierra-affected updates that explicitly says it affects the BootROM, but perhaps the description isn't detailed to cover that in all cases.
The reports say that ZombieLoad affects Intel processors since 2011 so I presume that 2010 MBP's are not affected by this specific vulnerability. But if the press attention generated by this makes people think about whether their non-affected computer is up-to-date with security patches, that's a good thing.
But there's more here. According to a Dell article I saw, the Microarchitectural Data Sampling Vulnerabilities are contained in CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091. In the Apple document linked above, these are all grouped together in a single "Microcode" entry so these are probably the affected CVE's. But - according to the Apple document, the security update to address this is only available in Mojave, nothing earlier. I don't see this fact being reported in the press (maybe I missed it) - so:
1) am I missing something? OR
2) did the Apple document omit that it was included in other OS updates? OR
3) will security updates for High Sierra and Sierra be coming later? OR
4) maybe the document is correct - no ZombieLoad fixes unless your computer is running Mojave 10.14.5?
(UPDATE: I see that for High Sierra and Sierra, Apple suggests going the "full mitigation" route - i.e., turn off hyperthreading.)
(BTW, this Dell document:
https://www.dell.com/support/articl...pact-on-dell-client-platform-products?lang=en
suggests that the ZombieLoad vulnerabilities are addressed in the OS, not the BIOS/BootROM. If anybody has information otherwise, please share it.)
Last edited:
There are mixed messages on this here: https://support.apple.com/en-us/HT210107
The 2010 MBP, among other older models is listed under this header: "These Mac models may receive security updates in macOS Mojave, High Sierra or Sierra, but are unable to support the fixes and mitigations due to a lack of microcode updates from Intel."
So, even without Hyper-threading there seems to be an issue on these older computers.
You may see between 0 and 4% performance loss without enabling the full mitigations. The partial protection can encur a performance drop, but it is extremely small if anything your workloads will surface at all
It will depend on what you do with your computer. Intel has this:
https://www.intel.com/content/www/us/en/architecture-and-technology/mds.html
I think there was some other article that Intel said 3% for consumer, 9% for data center.
In my own testing, which just involves H.264 and H.265 (x264 and x265 decoders) of a single 23-minute video, there was a 1% difference (worse) on my base 15" 2018 MBP in both x264 and x265 between 10.14.4 and 10.14.5 (without full mitigation which involves turning hyperthreading off). But on my 2014 Mini (mid-level), this difference was less than .3% for x264 and for x265, it was actually faster on 10.14.5. You have to take these figures with a grain of salt because with these small differences, it could just be natural variation - if I were to run an encode again with the same configuration, there could be 2% difference or no difference at all.
But - with another video, if I take a look at what the performance was with x265 encoding on 10.14.3 (non-supplemental) and 10.14.5, there was a 8.7% performance drop. The 10.14.5 was done with HandBrake 1.2.2 vs. 1.2.0 for 10.14.3 so there could be that difference. But I think it's possible that there was some mitigation going on in 10.14.4 or perhaps the OS itself became less efficient between 10.14.3 and 10.14.4.
I should do more testing on the 10.14.3 vs. 10.14.5 but it takes some time to dig out the old logs, figure out where it fit in my OS history and re-run the encode.
UPDATE: I tested 3 videos on my base 15" 2018 MBP macos 10.14.5 and loaded HandBrake 1.2.0. Using HandBrake 1.2.2 is about 5% slower using the x265 encoder vs. 1.2.0. On average, there was 2.5% additional performance drop vs. what I saw vs. encoding x265 in 10.14.3, all or part of which could be the OS (which may or may not include mitigations).
[doublepost=1558372783][/doublepost]
In looking at this list of Mac's that Apple is waiting on Intel for microcode updates, this corresponds to the earliest Macs that can run High Sierra and Sierra so perhaps we will see the ZombieLand mitigations for these OS's in the future. The list linked above says late-2010 Mac Pro but other references (including from Apple) says mid-2010 so I don't know what's going on there.
I know it seems like we're piecing this together as bit-by-bit but all of this information is scattered about in different documents - it would have been nice if Apple had put this information together in one logical document.
Last edited: