Slashdot Mirror
New Attack Bypasses Mac OS X Gatekeeper
msm1267 writes: Mac OS X's Gatekeeper security service is supposed to protect Apple computers from executing code that's not signed by Apple or downloaded from its App Store. A researcher, however, has built an exploit that uses a signed binary to execute malicious code. Patrick Wardle, a longtime Apple hacker, said Gatekeeper performs only an initial check on an application to determine whether it came from an untrusted source and should not be executed. Using a signed binary that passes the initial check and then loads a malicious library or app from the same or relative directory, however, will get an advanced attacker onto an OS X machine. Wardle disclosed his research and proof of concept to Apple, which said it is working on a patch, and may push out a short-term mitigation in the meantime.
I get that this is possible and all, but I think I'm failing to understand the threat posed by it that's any different from what was possible already by design. Gatekeeper has three settings (paraphrasing; #2 is the default, from what I recall):
1) Mac App Store only
2) Apps from registered developers only
3) Anything goes
It's already quite possible for a ($99/year) registered app developer to release a trojan and distribute it via the Internet to anyone using settings #2 and #3, but if they do so, Apple has been quick to revoke their certs (preventing all of their apps from installing on anyone's Mac using settings #1 or #2), pull their apps from the Mac App Store, and add the malware to OS X's built-in malware blocker that gets updated nightly.
This attack seems to rely on the actual bulk of the malware being downloaded separately from the main app that's been signed, which means that, as has been the case up until now, the user still needs to be coerced into downloading the malware themselves somehow. The only difference I can see (besides the addition of a lot of complication that makes the attack more difficult to accomplish) is that if the dummy app is able to be distributed via the Mac App Store, this may be a way to target users with setting #1, since otherwise the malicious payload would need to get through Apple's app review process. But if that's all that this attack brings to the table, it isn't much, since setting #2 is the default, meaning the target audience for this attack is particularly limited and that (by design) there are already easier ways to hit the bulk of users. Moreover, Apple's response would no doubt be exactly what we'd expect: to revoke the certs, pull the apps from the Mac App Store, and add the app to their malware blocker, meaning that the attack will stop working overnight.
Am I missing something more sinister here?
The exploit is for users with #2, registered developers. A bad guy who is not a registered developer can publish code which appears to be signed by a trusted developer.
The root of the problem is that it checks a signature on the -executable-, not the -package-. A typical package has a setup executable, which we'll call setup.exe. That's signed by Apple, Adobe, or whoever the developer is.
Setup.exe loads whattodoo.dll and runs some functions in it, then runs register_filetypes.exe, does some other stuff, then runs photoshop.exe. Neither whattodo.dll, register_filetypes.exe, photoshop.exe, nor the package the came in need to be signed. MOST of the executable code isn't signed.
A bad guy can download the Photoshop package and replace whattodo.dll and register_filetypes.exe with code of their choosing. Just rename backdoor.dll and botnet.exe. Mac treats it as signed because setup.exe is signed.
So the victim would download a malicious package and because setup.exe is signed, OSX would run it by default- thereby running backdoor.dll (renamed as whattodo.dll) and botnet.exe (renamed as register_filetypes.exe).
This is normally avoided on Linux by signing / hashing the entire package, not just one file in the package.