4 ms·

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 proc

• 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.
      • Xuzz 15y ago
        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.
  • guan 15y ago
    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 http://twitter.com/0xcharlie/statuses/133901782169550848