Mac OS High Sierra automatically checks EFI firmware each week | Hacker News Reader

Mac OS High Sierra automatically checks EFI firmware each week

eclecticlight.co

175 pointsmbgaxyz58 comments

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?

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.

A TPM can be used to avoid this -- the firmware can update PCRs with its own hash early enough that malware can't run.

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?

Couldn't it simply replace eficheck and not worry about anything else?

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.

I do believe the whole point of the TPM on macs is the make sure the firmware and ultimately OS is signed with Apple keys.

A lot of newer Intel CPUs can be programmed, via fuses, to refuse to boot unless the first-stage firmware hashes to a specified value.

In principle, eficheck could attest to the firmware's health to an Apple server. It's not entirely clear what it would accomplish UI-wise, though.

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?

rEFInd is just an EFI application. It doesn't replace the system EFI firmware (which runs before, launches, and provides services to rEFInd).

As to whether or not this tool will flag it, I suppose you'll find out shorty after installing High Sierra.

This feature was the subject of a talk at Ekoparty: https://www.ekoparty.org/charla.php?id=798

macOS Sierra already periodically checks the firmware for Thunderbolt Ethernet adapters:

/usr/libexec/firmwarecheckers/ethcheck/ethcheck:

usage: ethcheck: [ --save -b <eth nvram bin output file> ] [ --integrity-check [ -b <eth nvram bin input file> ] ] [ --show-hashes [ -b <eth nvram bin input file> ] ] [ --cleanup -b <eth nvram bin input/output file> [ --send-change-in-firmware enable/disable] [ --version]

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).

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.

Just checked my MacBook Pro...45 days. And yeah, that was likely for some updates.

How do I check this? (I’ll go ahead and discard my HN dumbass card with this move.)

Open Terminal.app from Spotlight or Applications/Utilities, then type "uptime" (without quotes) and press Return.

> then type "uptime" (without quotes) and press Return

Then again with quotes also works, as long as you balance them.

    > sw_vers -productVersion
    10.10.5
    > uptime
    22:37  up 58 days, 14:45, 7 users, load averages: 2.65 2.87 2.36

`uptime`

You can also open the menu from the apple icon > about this mac > system report > Software > "time since boot: x days"

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.

> why not check it at every boot?

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.

What he's saying is that he doesn't reboot often, and certainly not once a week.

My Macbook has been up and running without a reboot for almost a year.

You never update your OS?

Who reboots their machine? I don't do it for months.

with the 2016+ MBP, you'd reboot several times a week, due to crashes

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.

Late 2016 13” non-Touch Bar anecdata: have restarted maybe ten times total between purchase last winter and today.

That's a lot of reboots: almost once a month.

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.

Dell, HP and Lenovo all have such machines.

Do you use external monitors daily? Or dual external monitors? I suspect it has to do with the USB C driver or hardware that's buggy.

Crash almost always occurs on wake from sleep (when plugging in monitors and other USB C peripherals)

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 bought a MBP in July and rebooted it maybe ?twice?. It's never had a problem with crashing. Great machine, but the touchbar sometimes annoys me.

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.

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 available via the command line; if your Mac is supported, you can run it as often as you like.

I’ve been running the High Sierra GM since it was released a week ago.

Here's the command:

   usage: eficheck: [ --save -b <EFI bin output file> ]
                    [ --cleanup -b <EFI bin input/output file> ]
                    [ --generate-hashes [ -b <EFI bin input file> ] [ -p <Output folder path> ] ]
                    [ --integrity-check [ -h <EFI hash input file> [ -b <EFI bin input file> ] ] ]
                    [ --show-hashes [ -h <EFI hash input file> ] | [ -b <EFI bin input file> ] ]

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.

What are the potential impacts to the hackintosh community? I haven’t powered up my old one in a while and it’s tremedously out of date.

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.

Did you generate a valid serial number / model combo first?

It wasn’t my machine but I think that had been done. It thought it was a nice new iMac.

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.

Pleasantly surprised.

Uh. It’s not heavily sensitive information, has a show details button, and honors user choices. Why would there be any anger?

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.

Reply on news.ycombinator.com