Security researcher Charlie Miller booted from Apple Developer Program

Post by nookiemonster » Tue, Nov 08, 2011, 9:09 AM UTC

5hoom wrote: post #30

kstenerud wrote: post #15

Earlier quoted context omitted.

No, he explicitly violated the rule in order to test the hypothesis that a security hole he'd uncovered would allow unsigned code to be downloaded after release into the app store and run on the device. The sane response to this would be "Oh, we better fix that. Thanks. We're removing your app BTW." The Apple response was typical of a bureaucracy.

The lesson I would take away from this is that Apple should provide a mechanism for security vulnerabilities to be reported officially so that researchers don't have to engage in these sort of dubious activities. Whether they listen to the reports or not is another matter. Anyway, is there any special reason why reporting via https://ssl.apple.com/support/security/ won't work?

Post by chalst » Tue, Nov 08, 2011, 9:33 AM UTC

brisance wrote: post #29

jjguy wrote: post #11

It's a bad move for apple. A good relationship with the community of security researchers is crucial - they're talented folks and their research results grab headlines. It takes just a tiny amount of corporate humility and public thanks to win their respect, and in return get goodwill. Treating the community badly will get ensure the next guy won't even try to cooperate. Over the last several years, Microsoft's MSRC…

Hold on here. Is Apple expected to know Charlie Miller is a "security guru", and even if they did, why should he be treated any differently? Security researchers should be held to the same standard as regular developers when reporting bugs/flaws. RTM was convicted of a crime because of his curiosity, and here we have a security researcher who knowingly put users at risk. You ask me, Mr Miller got off lightly.

Post by chalst » Tue, Nov 08, 2011, 10:01 AM UTC

pvg wrote: post #10

guan wrote: post #2

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

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.

Post by guelo » Tue, Nov 08, 2011, 10:29 AM UTC

ubernostrum wrote: post #62

nodata wrote: post #59

Earlier quoted context omitted.

So how do you prove that it's possible to get this kind of exploit into the store unless you submit it to the store?

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.

Post by st3fan » Tue, Nov 08, 2011, 10:52 AM UTC

mikeash wrote: post #40

Xuzz wrote: post #19

Earlier quoted context omitted.

I'd agree more if he didn't submit — and get approved — a working exploit in their store. Without telling them about it. Edit: Now, I don't disagree that just banning him from the program isn't a great idea, and that pulling the app and having someone from the security team send him an email isn't a better one. But it's hard to say this that a bad move on Apple's part.

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.