There’s a very good chance that Xcode has been compromised.
The article refers to “Xcode” generically, but as we all know, there are a lot of pieces to this puzzle: I’m going to examine a few of them below. It’s your job to think about how these things might affect your own products.
Code without a source
Any libwhatever.dylib in your project contains code you’re not compiling from source. You don’t really know what that code is doing, do you?
To get an idea of the extent of this problem, try this:
$ find /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/ \ -name "*.dylib" -or -name "*.a"
I count 190 libraries available to iOS in the current version of Xcode.
Of course, open source code is easy to review. But even there, if you miss a simple goto, it can have serious consequences.
Third party build phases
Do you use something like Crashlytics? Every time you do a build the Crashlytics.framework/run binary is executed on your behalf. Does this code do anything beside process your .dSYM files?
Who knows? I sure don’t.
Chain of trust
As we’ve recently seen, breaking the chain of trust is remarkably easy given the right amount of privilege and malice.
We have all seen Xcode verify before launching. There are even simple ways to disable that check.
Unfortunately, these checks only verify the delivery of the binary code. There’s no check of the package’s origin or the toolchain used to create it.
Trusting trust
You can’t even trust your compiler. If LLVM is somehow compromised, even clean source code can become an attack vector.
Now think about the other problems above and how a compromised compiler can make them much more likely and pernicious.
Fuck.
Updated March 10th, 2015: More details on the specifics of the attack can be seen here.