Live data from Hacker News

Security researcher Charlie Miller booted from Apple Developer Program

news.cnet.com

91–100 of 116 posts

Re: Security researcher Charlie Miller booted from Apple Developer Program

#91
post #79
post #40

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.

It's trivial to bypass those checks anyway.

Re: Security researcher Charlie Miller booted from Apple Developer Program

#92
post #39

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

Such developers will just compile the code into their apps. It's trivial to hide it from the reviewers.

Re: Security researcher Charlie Miller booted from Apple Developer Program

#93
post #39

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

Reviewers check behavior, mostly not content. It's easy to hide code and activate it later. If you can break out of the sandbox, you don't need to download code to exploit that.

Re: Security researcher Charlie Miller booted from Apple Developer Program

#94
post #40

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.

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.

App review ensures no such thing. Put in your spyware with a timer so it doesnt activate for a week. Boom, reviewers don't see it, and users do.

Re: Security researcher Charlie Miller booted from Apple Developer Program

#95

Earlier 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

#96
post #40

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.

Running unsigned code is an exploit, my friend.

Why? What can you accomplish by running unsigned code that you can't accomplish by embedding a (e.g.) Python interpreter?

Re: Security researcher Charlie Miller booted from Apple Developer Program

#97
post #9

Earlier 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?

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

Re: Security researcher Charlie Miller booted from Apple Developer Program

#100
post #27
post #24

Earlier 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

FWIW, I've submitted a couple of (relatively minor) ones in the last couple of years. They were each fixed in the next update and I was credited in the security release notes.
Post reply on HN