Sony “Fixes” Support for macOS High Sierra Firmware Updater by Doubling Down on Severe Security Risks.
After installing the fresh system, I booted off it, unmounted the internal SSD, installed the Sony updater (which does not require the kernel hack on macOS El Capitan that High Sierra does), updated the Sony A7R III firmware, rebooted off the internal drive, wiped out the external SSD and reinstalled a fresh El Capitan on it for next time. That external drive goes now sits in a drawer for doing the same thing for the next firmware update.
That process is not perfect: really nasty malware could infect even an unmounted volume, but it’s reasonably solid protection, and I did it on a spare machine. To get it really right, disconnect the internal drive, and then hope malware could not tweak hardware stuff in the laptop itself.
Update 24 Jan 2018: this is my summary position on the matter, which other web sites are free to quote in full so long as they link back to this page:
The current status of the Sony firmware updater is unacceptable because it requires the user to assume that Sony software is free of malware. That the software is signed only guarantees that something was signed by Sony, not that it is free of any infection (infection could have occurred prior to signing). [Indeed, even malware can be signed].
If Sony software is ever compromised (including at the source code level!), that malware would have unfettered root/kernel access to the system until the system were wiped out (assuming such an infection did not overwrite firmware in various places, in that case the machine becomes dumpster material).
Since Sony Pictures with highly valuable intellectual property was hacked a few years ago (taking the company down for weeks), no user should ever trust what could become a “root kit” firmware updater for hackers.
The ONLY acceptable solution is an in-camera firmware updater. Even that is not risk free (the download process), but it does not directly expose the computer at the kernel level, or even admin level.
That there is risk is self-evident in Sony’s need to bypass what Apple now considers core security prohibitions. Indeed, the Sony kernel extension cannot just be installed but requires explicit enabling by the user after installation, that is, on the new iMac Pro with its secure enclave and much more locked down boot security.
Sony has made the Sony camera firmware updater problems FAR WORSE by explicitly requiring installation of a kernel extension. See the workaround suggestions in yesterday’s blog post. If you’ve heard the term “best practices” applied to any process such as security, Sony is doing the opposite: “worst practices”. But maybe Sony cannot do it right; perhaps there is some (grievous lack of foresight) hardware design error that prevents an in-camera firmware update as with Nikon, Canon, Fujifilm, Leica and others (but not Olympus).
The Sony kernel extension is (quite appropriately) BLOCKED by macOS because it is a very VERY BAD idea. The user has to OK the kernel extension in, a nasty thing to force upon a camera user, let alone a computer user.
Here is Sony’s risky “solution” complete with barely readable low-grade screens shots:
The barely readable tiny screen shots show an inattention to detail that reinforces my conviction that Sony doesn’t know what it is doing, or its impact on customers.
In this day and age, requiring a kernel extension to install a firmware update for a camera shows gross ignorance of the security risks and in my view, is incompetence.
The fact that a kernel extension might be signed (or might not) is no assurance: if a major part of Sony can be hacked and shut down for weeks, what’s to stop a hacker from infiltrating and putting malware into a kernel extension that millions will download, thus compromising the entire computer. I strongly advise NO ONE to go this route, even if you have to send the damn camera in to have it done.
Or, you can trust that Sony will never ever be compromised and install this worst-ever Sony root kit. But that’s a bad assumption: it’s not just that malware could infect the kernel extension, it‘s that the kernel extension even as designed could open up new security holes. Sony surely has not subjected its kernel extension to an external security review.
As for my Sony A7R III, maybe I’ll just send it back and buy a new one for now. Then I can defer having to bother.
Kernel extensions do have their place, for example, SoftRAID or the LaCie RAID Manager (both for storage support). Kernel extensions should be the last resort when no other options are possible, because kernel extensions have no security constraints whatsoever. Malware in a kernel extension or any security flaw could led to total system compromise—you lose everything meaning your bank accounts and so on, since such an extension can log all keystrokes and send them to Belarus or whereever. Woosh—you’e destitute and maybe your identity stolen for good measure.
Geoffrey R writes:
In re-reading your recent article (https://diglloyd.com/blog/2018/20180118_1156-SonyFirmwareUpdate-macOS-HighSierra-kernel-extension-fix.html) about Sony’s atrocious firmware update procedures, I’m reminded that a) I don’t miss my A7R, and b) I used to use VMware Fusion with macOS running in a VM dedicated just to Sony firmware updates. Doing so was much less disruptive than maintaining a separate partition on disk, having to reboot my machine, etc. I am not sure if the latest Sony kernel extensions run inside a VM, but I’m guessing they do.
Create a “lean” macOS VM (3-4 GB RAM + 40 GB disk is probably fine), install a fresh copy of High Sierra in the VM along with the myriad OS patches required, take a snapshot of the VM, then install the Sony kernel extension, update the camera, and restore your snapshot when done. Repeat this process to ensure a “clean” VM each time you need to update the camera, without having to disrupt your work on your host OS.
Bonus points for disabling network access in case Sony’s firmware updater is actually compromised; just drag their dmg you downloaded to your host machine into the VM and delete it from the host. This worked for me for several years. It’s not ideal, but it’s safer than a dedicated partition/host machine. (This process also works well with equally nasty Windows-only software/updaters I have for other pieces of antiquated hardware I own.)
Ensure the VM has no networking, no file sharing with the host OS, etc. Typical caveats about backup still apply though since the VM is likely to reside in a file on a drive your host uses for other tasks. I wasn’t paranoid enough to give my VM a dedicated physical drive but I could see why one might.
Thankfully, duplicating a clean state is easy with VMware’s Fusion — there’s a feature called snapshotting that actually creates a restore point you can jump back to any time. Any time you patch your clean OS, for example, you can create a new snapshot to update your clean state without having to keep multiple copies of VMs all over the place. (They’re also stateful so that if you copy the VM to another host entirely, you keep your snapshots even on the physical machine.) You could even start with a Sierra install, create a snapshot, update to High Sierra, create a second snapshot, and quickly jump between snapshots depending on your need that day — a software developer’s or tester’s dream.
Full disclosure: I worked for VMW as a QA engineer for a decade and do trust the software, though I never directly worked on Fusion. I understand Parallels has some performance advantages these days but I don’t much care about performance for my purposes so I go with what I trust.
DIGLLOYD: a virtual machine seems to be an excellent way to handle this—assuming the Sony updater works correctly. Keep a copy of macOS El Capitan on hand for installation into the virtual machine. I would argue against a dedicated drive and for a file-based virtual because a file is easily duplicated and backed up, and thrown away after one time use (a duplicate of the stock one).