It’s rude when according to the article he withheld details of the exploit to give Apple time to fix the bug, but the decision is understandable since he did violate the developer agreement. I’m not so sure about “interfering with Apple's software and services” but his activites seem to be covered under “hiding features from [Apple] when submitting them.”
The situation is only understandable from a 'blindly following the rules' perspective. If Apple makes it 'illegal' to probe their AppStore, then only black hats will be the ones doing the probing.
How are you supposed to test whether or not Apple will discover a vulnerability during their AppStore approval process if you are going to tell them that one exists?
In this case, he didn't only probe the approval process, but he also released the app containing the exploit into the store for public consumption. Apple's process allows for submitting an app for approval without releasing it into the store once it has been approved.
If the exploit potentially allows downloading and running of unsigned code after release in the app store, how else could one prove that it is in fact a hole, other than by releasing it into the app store to confirm the behavior?
Apps that you load onto the device yourself from Xcode are still signed, and are still governed by the sandboxing rules. You can demonstrate that the exploit works in your app by loading it on via Xcode, at which point the only difference submitting it to the AppStore makes is proving that it gets past the AppStore submission process (which isn't the interesting part about this exploit).
You cannot yourself with Xcode install the very same signed "Distribution" binary that you submit to the App Store. The closest you can get is one signed for "Ad Hoc" distribution, but even those binaries interact with the OS differently than a "Distribution" binary. In-app purchasing, for example, differs between the two.
That said, this guy broke the legal agreement that we partly rely on for trusted computing in iOS. He can be thankful if he doesn't get sued, and he should have gone about it differently if not willing to face the minimal consequences of violating the legal agreement.
You cannot, but the apps installed via Xcode have the same restrictions. In-app purchasing is at a much higher level than the kernel-enforced sandboxing rules that this exploit was affecting.
Putting the exploit in the App Store isn't particularly polite either and doesn't seem to serve any purpose other than generating some publicity for the researcher. It'd be different if he believed Apple wasn't going to fix it or that the exploit was being used or was about to be used in malicious apps - but he doesn't claim that was his motivation.
It seems he was pretty sure it was going to work - there's nothing magical about the App Store, he'd found a way to get around the code signing checks. I'm sure that once the vulnerability was fixed, he'd get credit. It's just that this sort of thing won't get you in forbes.
I personally don't really think there's anything at all wrong with a bit of harmless, nerdy limelight-seeking to boot, if that's what he was doing. Acting like he was somehow mistreated is what seems a bit iffy.
The problem is Apple could claim, "In our app verification process we can ensure such an exploit could never make it to the app store." The only way to test the full-scope of a vulnerability is to test it in a real world scenario, which means keeping it from Apple.
Unfortunately, I know of no other way to do it, unless companies like Apple create security groups that work with people like Charlie and give him an exemption to submit, and not notify other parties at Apple.
If that's the problem, it's a different problem. If I'm reading the article right, he did submit the exploit, companies like Apple do have channels to receive and respond to vulnerabilities and to credit people who find and report them. There's nothing in the information released so far on this that suggests he was, in fact, facing such a problem.
That's a bit too charitable to Apple, I think. Yes, the decision is covered by the terms of the agreement - they can do what they did. But since the result of their decision is 1) bad press and 2) increased risk of security holes, it's not "understandable" unless you think Apple is run by morons...
I think the risk is primarily bad press. It's not really a "security hole" for apps to add additional runnable code from an external website, when apps can currently contain pretty much anything at all (as long as they don't link to forbidden symbols). Remember that Apple does not see source code, and relies completely on app developers to behave, beyond a few perfunctory checks.
And Apple has made it abundantly clear that they don't care about bad PR in the security community. So there's really no downside to cutting out Charlie Miller, in Apple's eyes. The winner here is Charlie Miller's career.
I really doubt it. To be blunt, Apple is an existence proof that security on consumer products doesn't provide business value in proportion to its cost. Keeping users safe is seldom worth investing in.
That's sort of a strange thing to say considering that iOS and app store sandboxing are doing more to innovate in the security department than any other consumer device manufacturer.
Comments
It’s rude when according to the article he withheld details of the exploit to give Apple time to fix the bug, but the decision is understandable since he did violate the developer agreement. I’m not so sure about “interfering with Apple's software and services” but his activites seem to be covered under “hiding features from [Apple] when submitting them.”
The situation is only understandable from a 'blindly following the rules' perspective. If Apple makes it 'illegal' to probe their AppStore, then only black hats will be the ones doing the probing.
How are you supposed to test whether or not Apple will discover a vulnerability during their AppStore approval process if you are going to tell them that one exists?
In this case, he didn't only probe the approval process, but he also released the app containing the exploit into the store for public consumption. Apple's process allows for submitting an app for approval without releasing it into the store once it has been approved.
If the exploit potentially allows downloading and running of unsigned code after release in the app store, how else could one prove that it is in fact a hole, other than by releasing it into the app store to confirm the behavior?
Apps that you load onto the device yourself from Xcode are still signed, and are still governed by the sandboxing rules. You can demonstrate that the exploit works in your app by loading it on via Xcode, at which point the only difference submitting it to the AppStore makes is proving that it gets past the AppStore submission process (which isn't the interesting part about this exploit).
You cannot yourself with Xcode install the very same signed "Distribution" binary that you submit to the App Store. The closest you can get is one signed for "Ad Hoc" distribution, but even those binaries interact with the OS differently than a "Distribution" binary. In-app purchasing, for example, differs between the two.
That said, this guy broke the legal agreement that we partly rely on for trusted computing in iOS. He can be thankful if he doesn't get sued, and he should have gone about it differently if not willing to face the minimal consequences of violating the legal agreement.
You cannot, but the apps installed via Xcode have the same restrictions. In-app purchasing is at a much higher level than the kernel-enforced sandboxing rules that this exploit was affecting.
You could pull the app after confirming that the vulnerability exists and collecting evidence. Or tell the vendor that it's there:
http://twitter.com/0xcharlie/statuses/133901782169550848
Putting the exploit in the App Store isn't particularly polite either and doesn't seem to serve any purpose other than generating some publicity for the researcher. It'd be different if he believed Apple wasn't going to fix it or that the exploit was being used or was about to be used in malicious apps - but he doesn't claim that was his motivation.
Except that how else is he supposed to prove that it works other than actually demonstrating it with a real app on the real App Store?
It seems he was pretty sure it was going to work - there's nothing magical about the App Store, he'd found a way to get around the code signing checks. I'm sure that once the vulnerability was fixed, he'd get credit. It's just that this sort of thing won't get you in forbes.
I personally don't really think there's anything at all wrong with a bit of harmless, nerdy limelight-seeking to boot, if that's what he was doing. Acting like he was somehow mistreated is what seems a bit iffy.
The problem is Apple could claim, "In our app verification process we can ensure such an exploit could never make it to the app store." The only way to test the full-scope of a vulnerability is to test it in a real world scenario, which means keeping it from Apple.
Unfortunately, I know of no other way to do it, unless companies like Apple create security groups that work with people like Charlie and give him an exemption to submit, and not notify other parties at Apple.
If that's the problem, it's a different problem. If I'm reading the article right, he did submit the exploit, companies like Apple do have channels to receive and respond to vulnerabilities and to credit people who find and report them. There's nothing in the information released so far on this that suggests he was, in fact, facing such a problem.
I agree. To demonstrate an exploits effectiveness - it has to be exploited in a realistic situation (in this case the app store).
Part of the point was to demonstrate that the App Store code audit did not catch the exploit.
That's a bit too charitable to Apple, I think. Yes, the decision is covered by the terms of the agreement - they can do what they did. But since the result of their decision is 1) bad press and 2) increased risk of security holes, it's not "understandable" unless you think Apple is run by morons...
I think the risk is primarily bad press. It's not really a "security hole" for apps to add additional runnable code from an external website, when apps can currently contain pretty much anything at all (as long as they don't link to forbidden symbols). Remember that Apple does not see source code, and relies completely on app developers to behave, beyond a few perfunctory checks.
And Apple has made it abundantly clear that they don't care about bad PR in the security community. So there's really no downside to cutting out Charlie Miller, in Apple's eyes. The winner here is Charlie Miller's career.
The downside is poorer security, which could blow up in their face spectacularly at some point in the future.
I really doubt it. To be blunt, Apple is an existence proof that security on consumer products doesn't provide business value in proportion to its cost. Keeping users safe is seldom worth investing in.
Well, at least not until you get a sony-sized screwup...
That's sort of a strange thing to say considering that iOS and app store sandboxing are doing more to innovate in the security department than any other consumer device manufacturer.