> Is there any diagnostic tool out there to determine if you've been infected?
From what I can tell, they posted the SHA256 of the offending binary under the IOCs section of that web page. So you should be able to do this in the root of your home directory to detect if such a file exists:
# find . -type f -print0 | xargs -0 shasum -a 256 | grep 664e0a048f61a76145b55d1f1a5714606953d69edccec5228017eb546049dc8c
Binary checksums are usually not very helpful for identifying malware. The fact that the binary they were looking at was called "unpacked" suggests that there would be packed versions out there, and they would have a different checksum.
Yes. And the malware could be polymorphic. Or there could be multiple versions of the same "core" out there. It's not clear to me how sophisticated virus (malware) scanners for OS X are with dealing with that.
From what I know (which is not much) scanners, among other things, search for identifying patterns in files. So there is an identifying pattern of each discovered malware/virus in a database.
Thought experiment: let's say that Apple doesn't know what the suspect in a law enforcement investigation is suspected of. If the request is between revealing the identity of a user from a particular IP address (which is probably easy for them to determine), or giving away (essentially) a master key to decrypt all iPhones, which would it comply with? I think it would have complied with revealing the identity of a user pretty much every time, even if the suspect was a terrorist, but not necessarily to give away the master key for all iPhones even if the suspect was an intellectual property pirate.
Maybe it is a coincidence being posted on HN 7 months after the article was written, but the NY Post article is a great commentary on what is in the news these days:
To quote from the article: “Knockoff chargers sometimes cut corners,” Xiang said. “The quality of the capacitor and circuit protector may not be good, and this may lead to the capacitor breaking down and sending 220 volts of electricity directly into the cell phone battery.”
Apple trying to enforce its quality standards on the charging system seems completely reasonable -- yes, even if it means that the end-user has to pay for the quality. Most Apple customers are actually looking for that quality and willing to pay for it.
There is a great teardown analysis of Apple and knock-off chargers at Ken Shirriff's blog:
1. Apps in the Mac App Store can't ship their own kernel extensions along with the app. With the framework, it may not be necessary for virtualization products to do that -- enabling them to ship in the Mac App Store.
2. Compatibility breaks between OS version updates. Every time the kernel interface changes, someone shipping a kernel extension will need to ship an update as well. With this approach, it's possible to keep compatibility and let the implementation of the framework do all the heavy lifting.
3. If virtualization products are going to be in the kernel in order to run, it would be better for the host OS vendor to supply official supported interfaces instead.
Just as Intel is making it easier to do virtualization on their chips with VT-x and VT-d, Apple is making it easier to implement virtualization with Mac OS X as a host with this framework.
"Federal Reserve Regulation E guarantees that US consumers are made whole when their bank passwords are stolen. The implications lead us to several interesting conclusions. First, emptying accounts is extremely hard: transferring money in a way that is irreversible can generally only be done in a way that cannot later be repudiated. Since password-enabled transfers can always be repudiated this explains the importance of mules, who accept bad transfers and initiate good ones. This suggests that it is the mule accounts rather than those of victims that are pillaged. We argue that passwords are not the bottle-neck, and are but one, and by no means the most important, ingredient in the cybercrime value chain. We show that, in spite of appearances, password-stealing is a bad business proposition."
But that is really good protection for the consumer! I was not aware of that protection. I have heard of people being told by banks that their were no protections.
I don't think this is Apple trying to be difficult: SSD TRIM is buggy between all the different vendors (today even Ubuntu enables it only for Samsung and Intel SSDs by default), they want to guarantee that it works by whitelisting what they ship with, and the mandatory driver signing seems like a security improvement. If some third party wants to ship a signed kernel extension that works with their specific SSD (or generic ones, even) and supports TRIM, that should be possible.
FWIW, there is a third party SSD drive that works with Apple's default drivers for TRIM support; I suspect they're doing some sort of identifier spoof to fool the whitelisting code:
http://www.angelbird.com/en/prod/ssd-wrk-for-mac-929/
Does this whitelist drives that report themselves as a manufacturer of "Samsung", or does this whitelist drives that report themselves as "Apple".
If it's the latter, then they've functionally prevented me from ever upgrading a computer that I've purchased from them to add a new, larger hard drive. Now I cannot purchase a Samsung SSD from a third-party and have TRIM support (despite the fact that they ship the same drive, only changing the name reported as the manufacturer). Worse, a cursory glance at the store suggests that they don't sell SSDs as accessories, so I can't upgrade my drive at all and get TRIM support, even at crazy high Apple markup.
(I didn't find this advertised, but I suppose it's possible that the Apple Store may do this upgrade themselves, it seems totally crazy that Apple would completely prevent me from upgrading my disk.)
From what I can tell, they posted the SHA256 of the offending binary under the IOCs section of that web page. So you should be able to do this in the root of your home directory to detect if such a file exists:
# find . -type f -print0 | xargs -0 shasum -a 256 | grep 664e0a048f61a76145b55d1f1a5714606953d69edccec5228017eb546049dc8c