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.

Comments

There's an even greater flaw here.

[DejectedAngel]

OSX only checks the verification of the app if it sees that it is downloaded from a nonlocal source. If you download an unverified application, view package contents, and copy the files within to another folder and rename it with the .app extension, you can open anything! No admin rights required unless it requires an install!

Re:There's an even greater flaw here.

[IamTheRealMike]

Huh?

Gatekeeper is not meant to block any unsigned code execution. It's meant to stop you accidentally running malware. If you want to bypass it you can just right click on a .app and click "open", or you can disable it in System Preferences. The "attack" you just described is no attack at all.

It's not even clear to me that what's being described in the article is even an attack. OK, you can bypass Gatekeeper by finding an app that blindly runs code it knows nothing about. That's like complaining that if you run a signed browser and then it executes a malicious web page, bad things happen. That's not a bug in Gatekeeper. That's a bug in the browser.

History repeats itself?

[aicrules]

So even without the little pi symbol Gatekeeper is still full of holes.

Re:Gateskeeper

[Anubis IV]

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?

Bug is I can modify code signed by Apple

[raymorris]

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.

Gatekeeper

[soft_guy]

If a user doesn't know how and can't figure out or google how to bypass Gatekeeper, they shouldn't be bypassing Gatekeeper. I'm a Mac developer and I work on a commercial application that uses a privileged helper tool which the app loads using SMJobBless and that tool is managed by launchd and executed as root. We are an identified developer and we sign our app as such. We don't distribute via the App Store and we are about to ship a new version that adds a kernel extension that I wrote. In recent versions of MacOS X, kernel extensions must be signed and they have to at least by signed by an identified developer who has applied for a kernel extension signing certificate. One of the scenarios that I pay attention to as far as security goes is that our daemon (aka "privileged helper tool") executes other processes and also controls the loading and unloading of our kernel extension. Most of those processes, and our kernel extension, are located in our application bundle. I wanted to avoid making dumb assumptions like that our application is running from a particular path, so the app communicates to the daemon via XPC and tells the daemon where the app bundle is located. The daemon doesn't just trust the app. It verifies that the app is code signed and that it is our app and that it hasn't been modified before it starts executing things or loading kernel extensions from inside the app bundle. I can easily imagine a scenario where an app could call our daemon and tell it some other location and cause us to execute malware if we didn't do this. Since I'm not a security expert, I constantly worry that someone will find a way to do this and I just hope we never become an attack vector. I do not want my product on Slashdot because of a security problem.