Apple Blacklists Its Own Ethernet Driver
Apple blacklisted their own enet driver in a silent security update, SIP prevents fixing.
This software update was pushed via the silent “security updates” to my iMac today:
031-51913 | Incompatible Kernel Extension Configuration Data 3.28.1
After rebooting my ethernet didn’t work. Turns out that it added an exclusion for the stock AppleBCM5701Ethernet driver! This breaks ethernet and you have to use WiFi to get online.
I rolled the exclusion list back to the last version in my Time Machine backup to fix it, but this required booting from a recovery partition and was a huge pain in the butt, not to mention the time wasted finding the problem.
Matt Kulka (via Rainer Brockerhoff):
So apparently the version of the kernel extension for the built-in ethernet driver (AppleBCM5701Ethernet.ext) in OS X 10.11.3 has been added to the blacklist by Apple (AppleKextExcludeList.kext). Specifically versions lower than 10.2.0 have been blacklisted and version 10.1.12 is the one included in OS X 10.11.3.
The blacklist is dynamically pulled by OS X (it’s not part of a system update) and I’m not sure what the trigger is exactly. The mod date on the bad AppleKextExcludeList.kext for me was Feb 24. The “good” one is from Nov 12.
This is a result of Apple’s security processes working to disable kernel extensions Apple deems harmful. Also included in this update was the banishment of spyresoft’s Dockmod which somehow managed to get a kernel extension signed by Apple into production, in conflict with the security guidelines for OS X. This is a concern for a number of reasons, but that’s a matter for another day.
Fortunately, Apple realized their error in a short period of time, and pushed another Incompatible Kernel Extension Configuration Data update which removed the entry for the Ethernet Kernel Extension.
[…]
What remains to be seen is why they released this change now as opposed to after 10.11.4 shipped and had been in the field for some time. Given the catastrophic affect on systems, though, it’s possible this was just an intern with a faulty commit button that wasn’t caught. Neither make me feel warm and fuzzy about the state of software coming from Apple.
Unfortunately, this blacklist update appears to have inadvertently contained the kernel extension information for Apple’s own Ethernet drivers. This is a problem because blocking the Ethernet drivers means your Mac will not be able to connect to your network via an Ethernet connection.
[…]
If the Ethernet drivers are blocked, but the Mac has not yet rebooted, your Ethernet connection will remain working until the next time the Mac reboots.
Affected Mac computers that are connected via wi-fi will get the update and the Ethernet adapter will be once again detected and functional. But if wi-fi is unavailable, it won’t be possible to use deployment methods such as Munki, ARD, Casper etc, or wait for automatic updates to fix the error. Manual intervention is required, either connecting via external Ethernet adapter and running software updates, or transferring the fix manually with a Flash Drive. That could be a support-time problem in organisations that have ethernet-connected Mac labs, common in education.
[…]
After this error by Apple, IT organisations may need to consider testing Apple security updates before deploying them to their Mac fleets.
If the Ethernet connection on your Mac stopped working recently, check System Information to find out which version of “Incompatible Kernel Extension Configuration Data” is installed. If you have version 3.28.1, you need an update. If you can connect to WiFi, your Mac will update to version 3.28.2 automatically, or you can follow the steps below to restore it manually.
The reason, I think, that you have to issue the software update command via Terminal to get the fix is that the Mac App Store app will not run if the Mac doesn’t have an Ethernet interface. (And, in general, all apps purchased from the Mac App Store require the Ethernet interface at launch to perform receipt validation.)
The reason that you have to reboot from the recovery partition, if you don’t have Wi-Fi, is to bypass System Integrity Protection. This lets you delete the kernel extension blocklist so that you can use the Ethernet driver to access the network and software update.
Note that Apple’s example rm -rf command is incorrect. You should use straight quotes rather than smart quotes.
So TL;DR on the Apple #Ethernetgate event: The reason the update was sent out was to block a malicious app, Dockmod. The rest was errors.
Update (2016-02-28): Landon Fuller:
Presumably intended for >= 10.11.4, where Yukon2/BCM driver updates appear to fix local vulnerabilities in IOUserClient interface.
Dockmod seems have shipped a valid signed kext that allowed root to bypass SIP and inject code into processes (like the Dock).
That seems to have resulted in getting their signing cert revoked, and a blacklist entry added for their existing kext.
9 Comments RSS · Twitter
After watching Apple's software problems for a while and looking for a common thread, the cause for our increasing disappointment with them seems pretty simple. It's not that they don't have engineers able to create great software. It's a much more nefarious issue.
Apple doesn't understand QA.
"IT organisations may need to consider testing Apple security updates before deploying them to their Mac fleets."
People haven't been doing that already?
"After this error by Apple, IT organisations may need to consider testing Apple security updates before deploying them to their Mac fleets."
Thing is, how exactly would that work with a silent update?
@Chucky Right, I don’t think there is a setting that would have protected against this, other than turning off network access entirely.
"Right, I don’t think there is a setting that would have protected against this, other than turning off network access entirely."
Though I suppose one could use Little Snitch to block certain Apple addresses, which one could then turn off when they wanted an update.
(Assuming, of course, that LS still works in blocking deep-OS internet requests, and that the update mechanism addresses are known and predictable...)
@Chucky @Michael Are you saying there's a silent update feature separate from SysPrefs->AppStore->'Install system data files and security updates'? aka ConfigDataInstall?
You can check that one with
$ defaults read /Library/Preferences/com.apple.SoftwareUpdate
@Patrick I initially thought that the blacklist was fetched in the background and that this could not be stopped. I have not seen anything definitive from Apple, but my current thinking is that it’s controlled by the “Install system data files and security updates” preference.
John Siracusa says that there’s no setting to prevent the blacklist from updating.
