Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
OS X Security Apple

New Attack Bypasses Mac OS X Gatekeeper 66

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.
This discussion has been archived. No new comments can be posted.

New Attack Bypasses Mac OS X Gatekeeper

Comments Filter:
  • by DejectedAngel ( 4069599 ) on Wednesday September 30, 2015 @10:36AM (#50627309)
    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!
    • by IamTheRealMike ( 537420 ) on Wednesday September 30, 2015 @11:05AM (#50627569)


      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.

      • I think the other point of the "attack" (and I admit that this is pretty flimsy) is that an attacker could make malicious code *look* like signed and verified code, defeating the whole purpose gatekeeper helping prevent you from accidentally running bad things.

        I'd think the only solution would be to make every single executed snippet of code signed. I don't really know if that's possible though.
      • It's not even clear to me that what's being described in the article is even an attack.

        Then what is Apple patching?

      • Yeah. Seeing a gatekeeper bypass I was expecting, well, you know, something that actually *bypassed* gatekeeper. This in no way shape or form is a bypass.

        It *would* be considered a bypass on iOS, but that is because that platform attempts to prevent any unapproved code from executing. That is not a design goal of OS X. Irrelevant.

    • I hate it when I accidentally copy the contents of an apps package contents to another folder, renamed it with a .app extension, and execute it only to find there is malware inside.

  • by aicrules ( 819392 ) on Wednesday September 30, 2015 @11:05AM (#50627565)
    So even without the little pi symbol Gatekeeper is still full of holes.
  • Gatekeeper (Score:5, Interesting)

    by soft_guy ( 534437 ) * on Wednesday September 30, 2015 @01:24PM (#50628989)
    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.
  • Did they notify Apple of the problem and wait before publishing the details on the exploit, to give them a chance to push a fix before releasing the information to the public? It looks like they threw out the details of the hole into the wild before giving anyone a chance to patch it?

A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard.