Ever wonder what developing for the iPhone was like before the SDK shipped with iOS 2.0? I really enjoyed talking with Mark Bramhill and reminiscing about these early days.
Category: Development
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.
In the current version of xScope, there is a memory leak caused by a change in OS X 10.10.2. While the Loupe is in the background grabbing the screen, something in the frameworks is leaving images in the autorelease pool. The fix is literally two lines of code that forces the pool to empty.
But that’s not why I’m writing now.
This fix was submitted two weeks ago on February 2nd. A week later it went into review and was quickly rejected. The problem was that a buy button was accessible from our Help window.
The bulk of the help is static and built into the app, but there is a part online that we can update easily. This makes it really easy easy for us to add tips and other useful information for our customers. But since it’s just a web browser, it’s possible to wander into a part of our site that shows a header with mentions the word buy which is not allowed per rule 7.15. (Yes, the buy button is for something the customer has already purchased and is actively in the process of using, but technically it’s still a violation.)
My issue is the way that we must fix these problems. In this particular case, the issue was resolved by editing some HTML on our server, not by changing anything in the app itself. But we still must submit a “new” binary and go through the lengthy review process again. This is a huge waste of time for both developers and app reviewers (who are clearly lagging behind these days.)
I think there’s an easy way to fix these minor transgressions that would benefit both parties: add a new kind of approval with strings attached. A “Must Fix for Next Release” state where the app can go into “Ready for Sale” but the issue remains in the Resolution Center. At that point, both the app reviewers and developer know that an issue has to be dealt with before it’s approved the next time.
It would be like getting pulled over for a broken taillight on your car. You don’t need to visit your mechanic immediately to get the problem fixed. But you’ll certainly have to get things in order the next time you register the vehicle.
Please be sure to dupe Radar #19921616 if you agree that this would be a good change for iTunes Connect.
Right about now, Lenovo is learning the implications of installing security software that has not had peer review. Keeping all the pieces of the puzzle in memory and not using strong pass phrases is incredibly sloppy engineering work.
Any software that gets between you and your chain of trust should be considered malware.
We’ve been making award-winning apps since the App Store opened. Now we’re doing it for clients.