4 ms·

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 vi

by guan 15y ago

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.”

Codayus 15y ago
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...
- epistasis 15y ago
  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.
  - dasil003 15y ago
    The downside is poorer security, which could blow up in their face spectacularly at some point in the future.
    - ootachi 15y ago
      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.
      - deleted 15y ago
        [deleted]
      - smu 15y ago
        Well, at least not until you get a sony-sized screwup...
      - dasil003 15y ago
        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.
pyre 15y ago
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?
- btn 15y ago
  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.
  - kstenerud 15y ago
    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?
    - eridius 15y ago
      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).
      - masonlee 15y ago
        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.
pvg 15y ago
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.
- mpyne 15y ago
  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?
  - pvg 15y ago
    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.
    - kenjackson 15y ago
      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.
      - pvg 15y ago
        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.

by guan 15y ago

Codayus 15y ago

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...

epistasis 15y ago
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.
- dasil003 15y ago
  The downside is poorer security, which could blow up in their face spectacularly at some point in the future.
  - ootachi 15y ago
    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.
    - deleted 15y ago
      [deleted]
    - smu 15y ago
      Well, at least not until you get a sony-sized screwup...
    - dasil003 15y ago
      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.

pyre 15y ago

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?

btn 15y ago
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.
- kstenerud 15y ago
  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?
  - eridius 15y ago
    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).
    - masonlee 15y ago
      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.

pvg 15y ago

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.

mpyne 15y ago
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?
- pvg 15y ago
  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.
  - kenjackson 15y ago
    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.
    - pvg 15y ago
      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.