If the EFI firmware has been modified by a rootkit, surely it'll try to hide itself and present "valid" firmware data to the OS, and thus avoiding detection by this tool, right?
Surely a firmware rootkit can prevent eficheck from accessing TPM altogether or force the program to report everything is OK. If eficheck is not unsealing secrets stored in TPM, what would be benefits of checking PCRs?
That depends - it's possible to have a first stage bootloader in mask or OTP ROM that hashes the firmware before passing off control. No idea if Macs do this though.
Why bother with providing userland tool then? If you have complete chain of trust, the tool can just MsgBox("Everything's OK") because you wouldn't be able to boot OS if EFI didn't pass the check. If you don't have a chain of trust, the tool can be easily tampered with by the rootkit. Either way - it serves no real security purpose other than perhaps reassuring user or detecting obsolete, existing rootkits.
Yeah, it seems like this would have to be accomplished with a Management Engine application or something of the sort, otherwise probably easy to circumvent.
Seems the collection behaviour is also pretty straightforward to avoid, since you could just have an NVRAM region with the actual code in it, or a decryption stub.
Then again, at least it's something, no use raining on their parades.
>Yeah, it seems like this would have to be accomplished with a Management Engine application or something of the sort, otherwise probably easy to circumvent.
The correct solution to this is secureboot. No need for ME shenanigans.
If secureboot is functioning, then the wrong firmware wouldn't be installed to begin with by the time OS X gets to it, because it would not be allowed to run.
I'd really like to know the mechanism used for this. Currently Apple has issues with macOS firmware updates done on networks with proxies.
Specifically, the Touchbar updates have no concept of proxies and will cause the machine to appear to hang for a while (~20 minutes, IIRC) on boot when they can't directly phone home. This is a big problem on some large corporate networks.
i work at a fortune 50, had a mac mini that got borked... they said "will this fit in your backpack? can you sneak it home to fix it?" yup, sure could. kinda sad.
"Currently Apple has issues with macOS firmware updates done on networks with proxies."
They had the exact same problem with installing system images via proxied networks a little over a decade ago. I wonder if they're utilizing the same coders.
Personally, I use rEFInd to manage my MBP's OS installs. I know that it installs itself to the EFI partition, but would that cause this service to identify an insecure/corrupted/whatever EFI?
So the firmware could be compromised for up to a week, allowing a malicious 3rd party that long to exfiltrate whatever they want? If the problem of fake firmware is real, why not check it at every boot? Why not implement both UEFI Secure Boot, and also Measured Boot?
HIDS/HIPS has always been problematic because of chicken-and-egg rootkitability (ie a rooted box scanning itself is tantamount to worthless), also clean image scanning has been extremely inconvenient. It would make more sense to have an secure OS in ROM that runs at boot and at various times which bypasses the installed OS and drivers, and can scan firmwares, microcode on various buses and critical files. Basically, hardware TripWire, but with an authoritative signatures database. And certainly, UEFI Secure/Measured Boot is complementary for defense-in-depth.
Also, it would be helpful if PCIe, HDMI, USB, Thunderbolt, etc. drivers ask permission of the user before automatically connecting devices inserted into PCs... basically a peripheral "firewall." There are too many buses that are happy to give up the FSB and PCIe-side without authorization. Hell, it would be even better if buses used some sort of minimal-but-essential PKI and encryption.
> It would make more sense to have an secure OS in ROM that runs at boot and at various times which bypasses the installed OS and drivers, and can scan firmwares, microcode on various buses and critical files.
Isn’t that what Intel ME is? The only difference being we don’t know what exactly it does?
> Also, it would be helpful if PCIe, HDMI, USB, Thunderbolt, etc. drivers ask permission of the user before automatically connecting devices inserted into PCs...
Thunderbolt 3 does exactly this (at least on Windows). When connected to new hardware it asks whether to approve it or not (e.g. for Dell dock I had to approve both the dock and the cable).
For me that would be waaaay less often than weekly. Doing both would make some sense. Though a large sample like almost all OS users should mean everyone's week is different and an attack that involves multiple machines should start triggering reports very quickly.
The article doesn't specify, but I assume that "weekly" means "one boot per week", right? The kinds of malware that this type of check is trying to prevent would easily circumvent an OS-level check, no? I assumed this weekly "check" would happen before the OS is loaded.
I imagine the final productionized implementation would check either weekly or on boot, whichever is earlier. Only checking on boot would not suffice for many users (including me) who don't reboot their Macs for months.
You reboot more often than once per week? I sure don't. I'm at 16 days right now on my macOS Sierra installation, and I think the last time I rebooted was because I updated the operating system.
I don't remember exactly what settings I set at work, but I set various security settings to paranoid levels. There are three or four things that forget their cached authentication when the system goes to sleep, and so upon wake I get dialogs from those things the next time they need to do something that requires authentication.
I've found that it is actually much less annoying in the morning to start from scratch than to wake from sleep, because when I start from scratch I only have to enter my password once and it covers all of those aforementioned things.
This wasn't the case before I replaced the original hard disk with an SSD. It was then slow enough to boot that I'd find myself waiting with nothing to do.
The SSD is fast enough that it gets through the boot and to the password prompt while I'm still busy unpacking the breakfast I bring in to the office with me, and after I enter the password gets all my startup items launched and ready while I'm still finishing up unpacking breakfast.
It's all anecdotes and YMMV and all of that, but my work machine is a 15" 2017 MBP and I use it day in and day out running Xcode, Sketch, Paw, and a few other things and it doesn't crash any more often than my personal 15" 2015 MBP (which is rarely). Current uptime is 17 days, with the last reboot being tied to an update.
I suspect that either the 2017 spec bump fixed the issues present in the 2016 version or the crashes you mention are tied to specific software.
Yes, I have it plugged into a USB-C 2560x1440 27” Dell monitor all day, plugging it in at the beginning of the day and unplugging it at the end. At home I’ve also had it hooked up to HDMI and DisplayPort monitors via USB-C→ HDMI/DisplayPort cables (no docks/dongles). Neither have had a negative impact on stability.
I wish Apple would bite the bullet and release actual "pro" laptops with Xeons, ECC, and high end GPUs - similar to what it's doing with the iMac Pro. ECC would largely eliminate the need to reboot, as well as providing much better data integrity.
Late 2013 MBP here, since I upgraded to macOS Sierra, I've had crashes once or twice a week. It's gotten better in the last 2 months, so I think apple might have fixed some of the bugs.
It’s function is basically to top Apple off to the fact that there is something weird going on out there in the wild, rather than to offer individualised support/protection.
Since this appears to be strictly a notification for now, I expect Hackintosh users will see the message once, choose "Don't Send", and never see it again. According to the article, once you've made your choice, that choice is remembered between reboots.
Long term, I could potentially see this being modified to pop up every time on startup, as a "We know what you're doing, and we don't like it" signal to the Hackintosh users out there. However, that seems like kind of a dick move for such a small (and passionate) fraction of your market.
Tried to use iMessage on a hackintosh recently. Don’t do this, and don’t let anyone you know do it. Watching your services get switched off in a cascade is rather awful.
I wonder if there'll be any transparency around the database of known 'good' firmwares? For example, could a state actor force inclusion of a 'bad' firmware in the list? That's rhetorical, but the question is wouldn't it be better if end users could have visibility into the list of valid hashes? A count of the prevelance of each hash would pretty quickly highlight any with only a handful of appearances in the wild.
I'm a little surprised by how little chest thumping there is about apple collecting telemetry like this. I expected this to be full of people saying that you should only use tails and tor from a faraday cage.
because people aren't rational about this subject. on this site their are people with intense maximalist positions on privacy. they can be kind of shrill.
