Apple’s OS X Gatekeeper Leaves Hole Open for Malware and Adware - Here’s How to Protect Your Mac

| News

Apple introduced Gatekeeper in OS X Lion as a way to ensure users don't unintentionally run apps or installers from unknown sources. However, if someone is willing to personally (or professionally) identify themselves to Apple, then Gatekeeper will allow their signed apps to run on OS X, regardless of what those apps will do to your system. The reality is that this leaves too much room for malware and adware, including the example I found below.

For the purposes of Gatekeeper, Apple verifies the identity of the developer, but not their intent. It's up to you to ensure that the applications you install and run on your Mac come from the people you think they came from, and we'll show you how to do that.

A Nefarious Installer Bypasses Gatekeeper

As originally discussed in Mac Geek Gab 542, while clicking through to an article from (the reputable and source-curated site), a seemingly innocuous (but fake) Flash update message appeared.

The file I then downloaded was a disk image named, “adobe_flashplayer_e2c7b_Setup.dmg.” Double clicking on the .dmg revealed a very generic-looking "Installer" package. The attackers easily could have made it look better, even cloning Adobe's icons and styling. Still, this looks like a normal installer.

An Installer (Poorly) Masquerading as an Adobe Installer

Trying to run this installer by double clicking brought up a dialog that OS X presents for any app you’ve downloaded from the Internet. This is normal for applications, but not normal for Installer packages. That's because this attack is a full-fledged application masquerading as an installer by icon and name alone.

When encountering a new download, this is the first time you'll be presented with something that specifically identifies the file's source. Notice where the file was downloaded from: This is not Adobe.

Still, it looks normal enough, and continuing to run it brought up something that looked like OS X's normal Installer, except it wasn't. There are some very specific things unique to OS X's Installer that can help you identify what's going on.

True Installers Can Show Their Source

A Legit Apple Installer Certificate

In the image above, we have a legitimate Apple installer. There's a lock icon in the upper right-hand corner, indicating it is signed by a certificate. That's important because it means Apple has confirmed the identity of the creator. Clicking on the lock displays the certificate of the creator of the Installer. This is something you should do with every installer that provides this option. It's a very simple way to confirm that you're installing an app from the expected developer.

In the case of our nefarious Flash installer, the attackers built an application that looks like Apple's installer, but in the end is just another, normal application. Since the developers chose to identify themselves with Apple and get a certificate, Gatekeeper did nothing to stop us from running it.

And that's the problem. Gatekeeper is doing the job Apple intended for it to do, but it still leaves Mac users open to maliciously crafted malware and adware, as it did with the fake Flash installer.

Next: Who Signed the App and What Can Apple Do?

Popular TMO Stories



Install Flash on your computer? Bad choice. Not needed.


The idea is that when a developer misuses his/her signing certificate like this that Apple will revoke it. Then Gatekeeper should get an updated blacklist so other people won’t be able to install this fake app. I don’t know if they have an investigation or arbitration process before revoking the certificate or how fast Apple works on this, but I believe what I described above is the basic idea put forth when Gatekeeper came out.

Paul Goodwin

Also, I make it a habit never to download any software where I was notified of it via a popup while out on the net. If I get one, I go to the developer’s website via Safri (not a link in the popup) and look for downloads. I’m also suspicious of email notifications for SW updates. I don’t use the links in the email. Again, I go to the developer’s site and get the download - if indeed there actually is one.

Good info in the article above.


I always scan Adobe installers before attempting to run them and then I’m suspicious anyways.  It’ll be great once Adobe Flash becomes folklore and not an almost necessary evil!

Scott B in DC

I hate to tell you but there are a few places Apple cuts corners in CRL processing. There are CRL issues with certificates being stored in the keychain. If you receive a signed message in, it will automatically save the public key. You can use the public key at any time until it expires. Whatever the API supporting this does not do the CRL checking. Up until it expired, I was using a certificate issued by my old company (I recovered the private key from a USB drive).

I’m sure there are more cases, but this is something Apple has to tighten up!


There a lot of stupid user in this article.

1) You’re running Flash.
2) You downloaded the update from who knows where.
3) You ignored the badly developed splash screen.
4) You ignored the name of the web site in the dialog.
5) You didn’t check the subject name in the certificate.

So how much of this is Apple’s fault and how much of this is the user’s fault? At what point do users shoulder some of the responsibility?


Great Article.

“So how much of this is Apple’s fault and how much of this is the user’s fault? At what point do users shoulder some of the responsibility? ”

Apple has a system in place that can prevent code like this from being installed as easily by revoking the developer certificate. If they are unwilling to do this, the system will get abused. In my eyes, that’s their responsibility.

Of course users have some responsibility. That’s clearly outlined in the article in the last paragraph.

It is important to call these issues out or Apple may get complacent. I know I can avoid these nefarious installers, and I’m sure you can too. But I get concerned for those in my extended family that don’t have as much awareness as I do.



“There a lot of stupid user in this article…” Ah, the arrogance of youth.

The author of the article is John F. Braun, co-host of the Mac Geek Gab podcast. John makes his living troubleshooting and testing apps on the Mac, then he shares his findings with us. The fact that he shared his findings with screen shots shows he did none of the dastardly deeds you accuse him of perpetrating.

At least two of us think your comment is silly.


I thought the most important thing about Gatekeeper was that the developer must be known to Apple. Which means there is someone who can be sued if malware gets installed.

Maybe it would be a good idea for Apple to not just warn you that this is an app that you just downloaded from the internet. But really, really warn you if the app has “installer” in its name, or check for words like “adobe”, “microsoft”, “apple” and really warn you if the app doesn’t come from a site known to Apple.


Ok.  So whats a knucklehead to do if she fell for it ?
Any advise on removing it.


Amy, I feel your pain. I’ve fallen for well-disguised adware too. My latest solution is a donationware app, AdwareMedic -

It’s gotten good reviews on reliable sites. I’d suggest searching for opinions before downloading it however. If it doesn’t work for you, you can always drag it into Trash.

Good luck,

John F. Braun

Thanks for the comments and discussion to help others deal with adware and malware. 

The major point, which our friend “Scott B in DC” above, a frequent contributor to Mac Geek Gab who has pretty decent security chops IMHO, is that no matter the application that you apply a certificate to, be it a web site and SSL, or code signing for Gatekeeper, is that if one detects a bad player, but does nothing to revoke their cert or inform others that this has happened, this seriously puts into question the value of anyone having a certificate in the first place. 

To put in non-security terms, say I issue a driver’s license, but don’t revoke it if someone breaks the rules; what’s the point of issuing them in the first place?


I am a bit puzzled here, on a couple of counts.

First is with @jbruni’s five-point comment.
1. there is no indication that there’s a need for running Flash
2. downloads happen. Sometimes even when you don’t want them or expect them. Occasionally you touch something and it goes “POOF”. It happens.
3. the splash screen wasn’t that bad. And we can confidently expect the next iteration to be a perfect copy of Apple’s installer screen
4. dialog - here is where you have traction. This is the ONLY point at which a typical Mac user might blink. Many would not, but cautious ones will, and check
5. see (4). If you didn’t blink then you never thought to check. And, just by the way, I’m a long-time Mac user and never knew that the lock in that dialog was active, and would show the certificate. So - “what certificate ?”

The second puzzle is why Apple doesn’t distribute CRLs along with its other security stuff (I forget the name, but it’s the on that has the daily check, and invalidates bad version of Flash, etc, etc). This would be trivially easy to wrap into the daily download. Does anyone know why that doesn’t happen ??

John F. Braun

Thanks, @vpndev, from what I can tell from Apple’s own tech note on code signing, distributing a CRL (which I don’t think is normal practice) or using an active CRL or OCSP is certainly possible, but of course introduces network traffic and whatnot. 

The thing is if you look at the cert that Apple issues to developers, the field that identifies the criteria for checking revocation, which points to an OCSP source, is listed as Critical : NO.  So per their own guidance, they won’t do an active check because their cert (perhaps along with Keychain Access settings) says not to.


John: my experience with CRLs is a bit dated, but my understanding of the “critical: yes/no” setting was whether or not validation could proceed without one.

If the setting was “yes” then a CRL was mandatory, and verification failed if one was not available. If it were “no” then an attempt would be made to obtain one but verification would succeed if no CRL was available. But this might not be the correct and current interpretation.

What I had hoped is that Apple would include these CRLs with the daily download of malware signature stuff. Then the CRL-check would be entirely local, with no unexplained “waits” for the user to puzzle about. I think a once-a-day check would be quite sufficient.

John F. Braun

Good news, everyone!

Thought I’d provide a followup to this article and the piece of malware that was identified.

First, it looks like our friend Donny eventually had his certificate revoked

Second, if you now try to run this Installer, you’ll get a warning, thanks to the XProtect mechanism in OS X, that you’re trying to run “OSX.InstallImmitator.B” malware, and to not do that.

Log in to comment (TMO, Twitter or Facebook) or Register for a TMO account