Validating Your Version of Xcode | Hacker News Reader

Validating Your Version of Xcode

developer.apple.com

87 pointsdavidbarker97 comments

Am I understanding this correctly: the devs who downloaded Xcode from an unknown source disabled gatekeeper to get it to run?

That's unbelievably stupid dev behavior, if true.

They downloaded Xcode from somewhere besides Apple. How much more clue do you need about their stupidity.

Gatekeeper makes that a lot safer than you might think. The only downside is that it's not obvious how to check who signed it. If you could easily verify it's signed by Apple, that would be 100% safe.

$ spctl --assess --verbose /path/to/.app

I don't think having Gatekeeper disabled is a very big deal. It's one of the first things I disable on a new Mac. I've never had it stop an actual piece of malware, and it triggers false positives on practically everything.

That said, I have no idea why anybody would download XCode from a third party...

> That said, I have no idea why anybody would download XCode from a third party...

Easily explainable really. Went to [their favorite search engine], searched for "Xcode download" and clicked the first result which may not be from Apple (or an advertising).

Apparently downloads from Apple in China are very slow. So it's common practice to get it from a p2p network instead. I can totally understand it, but wouldn't do it myself (I think)

If you've had it disabled for a while, you should give it another go. Just about every app is signed now. I think the only one on my machine that isn't at this point is PopcornTime (for obvious reasons).

Actually, many Apple upgrades have a side effect of turning it back on, so I end up giving it another shot whether I want to or not every few months. Both my MBP and iMac had it turned on after the last Apple updates a few days ago, and I found out when I wasn't allowed to run something.

If it were just unsigned apps I wouldn't mind so much, but it's the stupid, "This application came from the internet..." dialog box that drives me nuts most of the time.

> I've never had it stop an actual piece of malware, and it triggers false positives on practically everything.

Well it would have stopped this actual piece of malware! How often are you installing unsigned applications that a single right click to add to a whitelist is too much effort?

> Well it would have stopped this actual piece of malware!

And I'm not infected by this piece of malware, so I still trust myself over Gatekeeper.

> How often are you installing unsigned applications that a single right click to add to a whitelist is too much effort?

Far more often than I install things from the app store. I don't find it to be a useful feature, so I disable it.

> And I'm not infected by this piece of malware, so I still trust myself over Gatekeeper.

That's idiotic.

Disabling gatekeeper is not uncommon, and was really common early on as many applications were not signed yet.

Downloading Xcode from a third party, now that's stupid.

I personally leave gatekeeper enabled. If I really need to run unsigned binaries I can just right-click -> open in the Finder. This way, any runs of unsigned code is only allowed because of an explicit per-instance decision on my part. It may be overkill, but I think the extra safety gained is worth it.

EDIT: I should mention that I work as an iOS engineer. Gatekeeper has not once impeded my work.

It's getting downloaded from a 3rd party because those 3rd parties are behind the Great Firewall in china.

Without those local caches the xcode download can sometimes take days or never finish at all.

Downloading from a 3rd party is fine IMO (after all the internet is just a big game of whisper-down-the-lane), but verifying checksums and signatures is incredibly important.

This was done in China and happened with the Chinese version of the App Store. In all honesty, like many things on the Chinese web it's likely difficult to find these resources.

Baidu isn't a very effective search engine and there are tons of people trying to get their mitts on user data including the government themselves.

If you're living in the land of gray-market computers/software, you'll never have gatekeeper installed to begin with. It's likely that the devs had disabled gatekeeper for other reasons - to run versions of local software also unsigned by Apple for lack of a (paid) Official Apple Developer Account.

No need to disable gatekeeper for that. Unsigned software can be run by launching via the right-click menu, which adds an "Open" button to the gatekeeper dialog box, allowing gatekeeper to be bypassed for hat one specific app. OS X will then remember that choice.

I see a lot of people saying they disable Gatekeeper on purpose.

Is the "right-click and open" trick that disables Gatekeeper for that app generally unknown? Or do people value not being assed to do it more than (potential) security upsides?

I wasn't aware of this shortcut until now. I've been going the long route through Settings. Thanks for the tip!

same. Awesome, but unlikely to be common knowledge IMO.

The right click trick works only if the app is not signed. If the app signature is invalid it won't work. You have to disable gatekeeper completely to open the invalid Xcode version.

Why would you do that?

> The right click trick works only if the app is not signed. If the app signature is invalid it won't work.

Is it possible that the malware version of Xcode had its signature removed?

Right-click and open doesn't always work.

It will fail if the signature is invalid.

Don't open it if the signature is invalid.

disabled gatekeeper to get it to run

Not necessarily - they might have disabled GateKeeper a long time ago and never re-enabled it. I have the same complain with Android's "allow software from third parties" checkbox - it's a little useless because you uncheck it for one specific app you downloaded, but probably leave it unchecked forever more.

If you run an app that gatekeeper forbids, when you go into settings to fix that there is a button to approve that single app. There's no need to let everything through.

Same with Android.

Is that new in M? I haven't seen that on Lollipop (5.1)

I'm fascinated that there are people on HN who have not disabled GateKeeper. I'm not sure i've used a machine since it was added where i haven't disabled it within an hour of setting up a machine.

How often do you install new software that's unsigned? I've only done it a couple of times, and once you override Gatekeeper for a specific app it never asks you for that one again.

I rarely find apps on the Mac app store, they're usually always from the app's creator's website. Recent ones I can think of include Bowtie and Sublime Text 3.

There's an option for app store + signed apps, which is fairly lenient. Bowtie I think is dead though, so it's possibly still unsigned at this point.

So? Once you open an app once (right click and open) it's white listed by gatekeeper.

Sublime Text 3 is signed:

    $ spctl --assess --verbose /Applications/Sublime\ Text.app
    /Applications/Sublime Text.app: accepted
    source=Developer ID

Or have you downloaded a special version from a Chinese file sharing website? :)

Most apps are signed nowadays, regardless of whether or not you're getting them from the store.

Why would you do that? It it exposes you to risk, and as has now been proven, if adopted as a general practice it exposes everyone else to risk too.

I do it because i do not use the App Store to download apps. Every open source app i download that is not signed with Apple needs GateKeeper disabled.

> Every open source app i download that is not signed with Apple needs GateKeeper disabled.

No.

Every unsigned app you download needs to be whitelisted. Right click the app, click open. It will remember your choice and whitelist the app forever more.

Solving the unsigned app problem by silently ignoring clearly invalid signatures is like solving an ant problem by burning down your house.

I keep gatekeeper disabled because I don't want app developers to have to sign up with (and I believe pay money to) Apple to setup a Developer ID.

(but I also don't download Xcode from random places)

It's easy enough to run unsigned apps, you just have to ctrl+click and select "open" then you'll get a different prompt that allows you to install the app anyway.

I suppose you can argue that, if that's the case, what's the point? Well, if you think that a piece of software should be signed but it is in fact not signed properly, then that's a clue that it's been tampered with. If the software isn't signed at all, then at least I can decide whether I trust the source enough to install it.

> Am I understanding this correctly: the devs who downloaded Xcode from an unknown source disabled gatekeeper to get it to run?

This is generally known as hubris. We think we're smart and that the rules don't apply to us, because we know better than the other people. Turns out they can protect us too. Who knew?

In this instance, I'd give the Chinese developers the benefit of the doubt, having recently had first hand experience myself of just how obstructive and irritating the great firewall can be (I was struggling to download small files my entire visit, like a 10MB pdf; I can't imagine trying to download a multi-gigabyte file). So perhaps this was the only way they could get work done–in which case it's on Apple to improve their CDN within China.

More broadly, it seems like though there's a careful line to be walked between locking down a computer (e.g. gatekeeper, system integrity protection) and keeping it 'open', I'm personally much more in favour of the former by default provided that the end user can disable it if necessary. It seems like the only realistic option going forward. Perhaps Xcode should be included under the SIP umbrella too?

The whole point of Gatekeeper is that you can download your software from anywhere and it'll integrity-check it for you. "The downloads were too slow" has no bearing on "and then I saved three minutes by skipping the security check on the software I got from an untrusted site."

:-(

Absolutely, but one might just suspect that the download was corrupted, no? Especially in these circumstances. I think as developers we have a responsibility not to assume that, and to be diligent, but I can understand how it happened.

in which case it's on Apple to improve their CDN within China

I'm not quite sure why it's up to anyone outside of China, Apple included, to bear the cost of China's firewall dickery.

This is on China to turn off their firewall or bear the costs, commercial and otherwise, of this stupidity. Perhaps Chinese developers shouldn't be allowed to submit apps to the non-Chinese app store?

Apple is in China.

Any time one of those "Quickly set up an OS X dev machine!" setup scripts makes the rounds, you can practically guarantee that the script disables Gatekeeper and the file download quarantine because the author "found it annoying/useless/pointless/mai freedums". You end up with one guy intentionally shooting himself in the foot, and 100s of others running his "helpful" script and shooting themselves in the feet without even realizing it.

Developers as a group are at least as stupid about security as everyone else.

The XCode trojan author is believed to have also backdoored the Unity3D engine. https://news.ycombinator.com/item?id=10256998

So, the next Trojan version of Xcode also needs to replace or corrupt spctl.

I should look at it (on iPad currently), but it seems like the right combination of a custom Certificate Authority added to the keychain and signing your malicious Xcode with a certificate signed by the CA would help. Maybe also change the quarantine metadata on the file?

> seems like the right combination of a custom Certificate Authority added to the keychain and signing your malicious Xcode with a certificate signed by the CA would help

nope. Gatekeeper only accepts certificates issued by Apple. The trojan would have to patch gatekeeper itself which will be difficult once people upgrade to 10.11 and keep the System Integrity Protection enabled.

Even with all the bad feelings about Apple taking more and more control away from us, there's also a huge upside to this practice, I have to admit.

I guess as long as stuff is turnoffable in emergencies, I can live with the restrictions.

I think this Tech Note says otherwise. It talks about Enterprise being able to manage code signing outside of Apple, and I believe it says with admin privileges a user can mark a CA as valid for code signing. I think code signing is voodoo for most developers, and therefore believe you could fool most of them into accepting the change if an appropriately worded dialog preceded it.

https://developer.apple.com/library/mac/technotes/tn2206/_in...

I'm not sure. The way I read this is that enterprises can disable Gatekeeper and then add a CA by which the binaries need to be signed.

Gatekeeper seems to really be tied to Apple's CAs.

Of course, if you're willing to download XCode from a shady source, you're also willing to disable Gatekeeper when it prevents you from launching your shady copy, so the point is moot I guess.

edit: Stackoverflow seems to agree: http://stackoverflow.com/questions/11833481/non-apple-issued...

That'd be fairly difficult under El Capitan as long as the user hasn't disabled rootless (even su/sudo can't modify system files with rootless on). Not sure about the signing part.

Just put a copy elsewhere and surreptitiously edit PATH so that the malicious one gets picked first. No need to delete any files.

Unless the binary is signed properly, that'll trigger the gatekeeper warning, with the the dialog mentioning a cryptically-named binary and the icon showing as a generic "headless program" terminal-looking icon. If that doesn't set off all kinds of red flags you probably deserve infection.

I thought Gatekeeper only applies to GUI launched programs?

I can't remember if Xcode asks for admin privileges or not when you install it...

...mind you, I guess that doesn't matter. If I unknowingly had a hacked version and it prompted me for my password at install, I would enter it.

I think it does, the first thing it needs to do is "Install Additional Components" (the updated mobile device framework)

it does

It does — it requires root to agree to the XCode license:

https://stackoverflow.com/questions/26197347/agreeing-to-the...

This seems to even be required to run things like the stock git or gcc, which I've always wondered how that isn't a violation of the GPL.

You need it for the installer to install it. I haven't read the agreement, but perhaps it makes clear that it only applies to the Apple licensed products.

Yeah, I ran across "You must agree to Apple Terms and Conditions" when running command line make after an Xcode update last week.

So, then you have to run sudo make to invoke the global license agreement console interface, then you manually type 'agree', then it runs the original command, except now you're running under sudo. In this case, that means it ran make as root, leaving root-owned artifacts all over my source tree.

One should of course verify its integrity BEFORE installing it and letting it replace spctl.

The real question is whether the spctl tool displays "Apple" in case of a valid (relative to generic CAs) certificate issued to "Apple". Hopefully that's not the case.

Another risk is a specifically designed executable capable of compromising spctl.

On machines with Gatekeeper enabled you won't be able to open the application without it verifying the signature. Devs would have to on purpose remove that protection to run this bad version of Xcode, and after that it is practically game over.

How about an "install" script, written in your scripting language of choice? Sufficiently obscure language, obfuscate the code, leave misleading comments and copyright statements to look like its from Apple...

It might work, but an "experienced" developer might know that there no install script for Xcode (also, an experienced developer will probably not download from a random server, so i guess that's something...)

So, the next Trojan version of Xcode also needs to replace or corrupt spctl.

I think that's what SIP is for: https://en.wikipedia.org/wiki/System_Integrity_Protection

Some news sources said Angry Birds 2 was trojanized, but "only" for the Chinese version. Anyone have any more info on that? Because I didn't think you could have separate binaries per location? Unless it is actually two entirely separate apps? And why would they even have a separate binary for the Chinese market (and why would they use a different build environment?)

It appears that a Chinese company named Kunlun licensed IP from Rovio and is developing Angry Birds apps specifically for the Chinese market. Perhaps they're also distributing the app themselves.

http://www.rovio.com/en/news/press-releases/621/rovio-gets-w...

Interesting.

Can you imagine the damage done to Rovio's credibility, simply because their licensee got hit? The news sites only talk about "You should delete Angry Birds 2". Nobody ever mentions or explains this third party.

The responses on this thread seem to prove that Apple knows what it is doing with its security strategy. The fact that people blindly disable protections and end up causing massive malware outbreaks is exactly the reason they are introducing things like Gatekeeper and Rootless. Arguably, this incident is evidence in favor of them locking down Gatekeeper further.

What output is expected when you run the command? I get:

  $ spctl --assess --verbose /Applications/Xcode.app
  /Applications/Xcode.app: rejected
  source=obsolete resource envelope

I downloaded XCode via the app store, but have disabled gatekeeper (re-enabled it before running this command).

  /Applications/Xcode.app: accepted
  source=Mac App Store

  /Applications/Xcode.app: accepted
  source=Apple

  /Applications/Xcode.app: accepted
  source=Apple System

Are the only valid options. You should remove XCode and reinstall it from Apple.

I get this with latest XCode from the App Store:

    $ spctl --assess --verbose /Applications/Xcode.app
    /Applications/Xcode.app: accepted
    source=Mac App Store

I got:

    /Applications/Xcode.app: accepted
    source=Mac App Store
    override=security disabled

Which I think means I have Gatekeeper disabled, but it still gave me the 'accepted' response.

I also have this. I'm curious if I have a hacked version.

Okay, yes it means Gatekeeper is disabled after enabling the feature I see the expected output.

jzollars$ spctl --assess --verbose /Applications/Xcode.app /Applications/Xcode.app: accepted source=Mac App Store

Spctl(1) gives you Gatekeeper's acceptance status. If you disabled it, it will (almost) always say "accepted", but in this case it may be "accepted because you turned me off, you XXX." Check the spctl(1) manpage for more options. A recent version will support the --enforce-assessment option to tell you what the real answer is. And turn the dang thing back on while you're at it. :-)

Even if you download from the AppStore, if any bits are corrupted it will be rejected, and rightly so.

Which xcode version is this? Maybe you have one from the stone age of "Code Signing V1" (pre-OSX 10.9.5), instead of the current "Code Signing V2"?

What version of Xcode? I get that with 5.1.1

The problem with "spctl" is that it also evaluates trust which depends on your system settings and you have to pay attention to the output (as pointed out in the article). If you only want to verify the code signature _and_ provide your own requirement string, you could use something like (long options for legibility):

    $ codesign --verify --verbose --deep --test-requirement "=anchor apple" /Applications/Xcode.app/

The "anchor apple" means Apple’s own code, signed by Apple ("anchor apple generic" for developer IDs too).

Add verbosity for all the gory details:

    $ codesign --verify --verbose=999 --deep --test-requirement "=anchor apple" /Applications/Xcode.app/

Note that "anchor apple" means "signed by Apple's build system". It will not cover the Xcode you get from the Mac App Store (it uses a different kind of signature). This incantation is good enough to check for "an Xcode I legitimately got from a web page download."

I'm getting "a sealed resource is missing or invalid", with a copy of Xcode I know was installed from the App Store. Any ideas?

If you use `codesign -v --verbose /Applications/Xcode.app` you may see:

  file added: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man/whatis
  file added: /Applications/Xcode.app/Contents/Developer/usr/share/man/whatis

That should be safe.

It's a bit of a shock that Apple:

1) is modifying sealed containers post-install (it's the weekly periodic job that rebuilds whatis database from installed man pages)

2) doesn't realize this and has put out instructions that will cause lots of false positives

Thanks! Yep that was it, I owe you one.

Yes, there are connection problem downloading Xcode from Apple'site. Since there is GFW.

But my biggest question of why, Apple manage to get CDN for their Live Streaming Event, App Store, and Mac Apps but not for their developer references and tools.

A honest mistake? Or Sloppiness from their Cloud "Services" again?

Presuming, of course, that whatever process may have corrupted your version of Xcode didn't also corrupt spctl.

Heh.

That shouldn't be possible after OS X 10.11: https://en.wikipedia.org/wiki/System_Integrity_Protection

I've just run the recommended check on freshly downloaded older versions (5.1.1 and 4.6.3), and their both appear rejected (source=matched cdhash).

These are explicit overrides programmed into Gatekeeper to deal with weak Xcode signatures during the transition time to stronger signatures. They're not a danger. Of course, Apple will tell you that you should use newer devtools than that. :-)

I wonder how Apple could even tell that the apps in question were built with a counterfeit version of Xcode.

They probably scan for tell-tale trojan strings (like the C&C hostname) in the binaries.

I always download the XCode from AppStore, I didn't even know you can do it from another source :D

Reply on news.ycombinator.com