Earlier quoted context omitted.
This hardly qualifies as an exploit. While it allows the app to do something it's not supposed to do, the ability to download and execute additional executable code doesn't actually violate security. The new code is still restricted to the app's sandbox and can't do anything that the original app couldn't potentially have done directly.
I think it qualifies as a great exploit. You totally go around the Private API checks that Apple does. And there is a lot you can do with those APIs that is potentially evil. Even in the sandbox.
Security researcher Charlie Miller booted from Apple Developer Program
91–100 of 116 posts
Re: Security researcher Charlie Miller booted from Apple Developer Program
#92Earlier quoted context omitted.
He did not put users at risk. This vulnerability allows apps to download and execute new code, but that new code is still subject to the app's sandbox. This vulnerability is interesting from a research standpoint, but has zero actual consequences to the security of iOS.
Not sure I agree with this. Less scrupulous developers might use this to download code that does things, even from a sandbox, that are bad for users. For example, it could download code that reports your usage habits to third parties, or saves your CC number.
Re: Security researcher Charlie Miller booted from Apple Developer Program
#93Earlier quoted context omitted.
He did not put users at risk. This vulnerability allows apps to download and execute new code, but that new code is still subject to the app's sandbox. This vulnerability is interesting from a research standpoint, but has zero actual consequences to the security of iOS.
Surely you don't think that having arbitrary code placed within the IOS AppStore isn't a security risk do you? Once malicious code has been approved in the store an attacker need only find a way to break out of the sandbox, which I am sure is possible.
Re: Security researcher Charlie Miller booted from Apple Developer Program
#94Earlier quoted context omitted.
This hardly qualifies as an exploit. While it allows the app to do something it's not supposed to do, the ability to download and execute additional executable code doesn't actually violate security. The new code is still restricted to the app's sandbox and can't do anything that the original app couldn't potentially have done directly.
It easily qualifies as an exploit, given that Apple's app store model is based on the fact that each app is reviewed beforehand to ensure various properties, including the property that the app does not contain spyware, etc. If Apple approved a harmless app, and then said app downloaded code that snooped on the user's calls or asked for their credit card number, that's an exploit.
Re: Security researcher Charlie Miller booted from Apple Developer Program
#95Earlier quoted context omitted.
So how do you prove the DDoS vector exists unless you DDoS someone's site? How do you prove the SQL injection vector exists unless you take over someone's site? etc., etc. This was far from a harmless proof-of-concept app, and "I just wanted to prove I could" isn't sufficient justification for it.
Since he has control over pricing, couldn't he submit with a free price tag, and change it to something insanely high once accepted. That way no sane person would buy it, and he'd still prove his point. He _had_ to submit an app and get it in for this to work ofcourse, otherwise this was a moot point. And it's a good wakeup call to everyone. Security awewareness helps sometimes unfortunately when you make a splash.
> .. otherwise this was a mute point.
"moot". Pretty please, the word is "moot."Otherwise, while I think you've got a point (he could have used pricing to ensure no one ran his app), that isn't the issue here. The disclosure is. No one is contending he did something evil with his code, it's that Apple is mad about his code and disclosure. I don't think making it unlikely to be purchased would have helped.
Re: Security researcher Charlie Miller booted from Apple Developer Program
#96Earlier quoted context omitted.
This hardly qualifies as an exploit. While it allows the app to do something it's not supposed to do, the ability to download and execute additional executable code doesn't actually violate security. The new code is still restricted to the app's sandbox and can't do anything that the original app couldn't potentially have done directly.
Running unsigned code is an exploit, my friend.
Re: Security researcher Charlie Miller booted from Apple Developer Program
#97Earlier quoted context omitted.
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?
Re: Security researcher Charlie Miller booted from Apple Developer Program
#98Re: Security researcher Charlie Miller booted from Apple Developer Program
#99Re: Security researcher Charlie Miller booted from Apple Developer Program
#100Earlier quoted context omitted.
He is foolish if he did not expect this. My guess is he's doing it for the notoriety and succeeded. A job well done. Next time he either should submit a bug report to Apple or avoid using their products.
when you submit a security related bug report to apple - granted my experience dates from 99-2005 - you get: A/ ignored (mail auto reply "we might fix it, don't tell anyone or we'll go after you" B/ bug don't get fixed for 2 or 3 years C/ bug get fixed, you get no credits