7 ms·
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 firmwar
by cmurf 9y ago
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?
- burntrelish1273 9y agoHIDS/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.
- colejohnson66 9y ago> 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?
- hdhzy 9y ago> 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).
- aaronbrethorst 9y agoYou 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.
- jclardy 9y agoJust checked my MacBook Pro...45 days. And yeah, that was likely for some updates.
- JumpCrisscross 9y agoHow do I check this? (I’ll go ahead and discard my HN dumbass card with this move.)
- miles 9y agoOpen Terminal.app from Spotlight or Applications/Utilities, then type "uptime" (without quotes) and press Return.
- masklinn 9y ago> then type "uptime" (without quotes) and press Return Then again with quotes also works, as long as you balance them.
- grzm 9y ago> sw_vers -productVersion 10.10.5 > uptime 22:37 up 58 days, 14:45, 7 users, load averages: 2.65 2.87 2.36
- deleted 9y ago[deleted]
- holyjaw 9y ago`uptime`
- wingerlang 9y ago
- nishs 9y agoI 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.
- jonknee 9y ago> 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.
- apetresc 9y agoThe 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.
- cakedoggie 9y agoWho reboots their machine? I don't do it for months.
- jordache 9y agowith the 2016+ MBP, you'd reboot several times a week, due to crashes
- kitsunesoba 9y agoIt'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.
- geerlingguy 9y agoLate 2016 13” non-Touch Bar anecdata: have restarted maybe ten times total between purchase last winter and today.
- copperx 9y agoThat's a lot of reboots: almost once a month.
- Recurecur 9y agoI 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.
- jordache 9y agoDo 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)
- alwillis 9y agoIt'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> ] ]
- Angostura 9y agoIt’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.