Live data from Hacker News

Disclosure of three 0-day iOS vulnerabilities

habr.com

311–320 of 464 posts

Re: Disclosure of three 0-day iOS vulnerabilities

#311

Earlier quoted context omitted.

I imagine they are just overwhelmed. Let’s say they have a team of 6 engineers tasked with this. They probably receive hundreds of reports a day, many bogus, some real, but all long winded descriptions like this framed to make the vuln seem as bad as possible. In addition many vuln reports are generated by automated tools and sprayed to thousands of sites/vendors daily in the hope of one of them paying out, they seem…

> Let’s say they have a team of 6 engineers tasked with this. They are a trillion dollar company. They can have as many engineers as they'd like.

You'd probably be surprised how small some departments are at large companies, if they're seen as a cost centre rather than a profit centre.

I agree they could and should do a lot better, I'm just imagining the probable reasons for this level of dysfunction - the most likely explanation to me is an overwhelmed, overworked department submerged in so many requests that they can't filter out the useful ones or respond in a timely way.

Just as one other example of this, the bug reporting system at Apple is antiquated and seen as a black hole outside the company, probably again due to underinvestment.

Re: Disclosure of three 0-day iOS vulnerabilities

#312

Why anyone at Apple decided that it was acceptable to log medical data in such an unsafe way? I currently work in an IT health care company in Europe, and we must alway store the data fully encrypted with strict access control. We even decided to not make sure to not persist any medical data on user devices to not take unnecessary risks. And there, Apple logs everything on the iPhone? Why?

I have some doubt with respect to whether what author claims is "medical data" is indeed medical. Practically speaking, the data he mentions seems like the things collected by Apple Watch and stored in the Health app. There is indeed heart rate tracking, but can we really label this data as medical? IMHO "medical" would relate more to professional diagnosis, treatment etc. which according to Apple is stored in an enc…

Even if "health data" and "medical data" aren't synonymous, it's a distinction without a difference to their privacy importance.

Re: Disclosure of three 0-day iOS vulnerabilities

#314

Earlier quoted context omitted.

> Apple used to be the company that made devices that were secure and "just worked". This is a complete myth. In fact, not only did Apple devices break all the time, but they were near-impossible for regular users to repair on their own. A simple proof: how many broken iPods did people used to have lying around?

I've never even heard of a broken iPod, who are these people that have several lying around?

Way back when they had spinning disks, they were pretty failure prone. Although they were easy to replace, I vaguely remember replacing one myself.

Re: Disclosure of three 0-day iOS vulnerabilities

#316

Earlier quoted context omitted.

And if you try to deploy these in an actual app, you will be getting banned very, very hard.

Do you have any evidence that Apple has been checking for these vulnerabilities in apps? I mean, if you tried now, sure, I'm guessing you'd get caught (or will be soon). But these have been around a long time.

No, I mean if you try it now.

Re: Disclosure of three 0-day iOS vulnerabilities

#317
I'm not defending Apple but looking at the code published here, it's clear that most, if not all, of these bugs could be caught via static analysis which Apple obviously uses as part of its approval process.

Frankly, I'm a lot more concerned with bugs that have to deal with input handling than SDK bugs that developers can use to do bad things.

This is likely a non-issue for those of us who haven't jailbroken our devices.

Re: Disclosure of three 0-day iOS vulnerabilities

#318
post #67

It must be nice to give up $100k by being impatient. I do understand that OP probably feels a moral reason to do so, but that $100k would be life-changing for me, even if it took 3 years to pay out.

This fellow has a lot more to gain than $100k by the popularity and prestige he'll gather from publishing this. Especially considering that Apple will never change their ways until they're publicly shamed, the long term outcome of shaming them is worth more than $100k if they actually change the policies to take security researchers and the bug bounty seriously

I would not consider Apple particularly concerned about shame in regard to bounty program delays in communication and publication, no matter how much people try.

Re: Disclosure of three 0-day iOS vulnerabilities

#319

Technology today on the software side is broadly at the place medicine was with elixirs and potions. Given the variability in medical practice across the US maybe it's still a prevalent pattern in different form.

100%. Perhaps medicine is not that far ahead either. There's a a number of drugs (esp. the ones that deal with the brain) where we observe the effects but the mechanism of action is not well understood.

Re: Disclosure of three 0-day iOS vulnerabilities

#320

I'm not defending Apple but looking at the code published here, it's clear that most, if not all, of these bugs could be caught via static analysis which Apple obviously uses as part of its approval process. Frankly, I'm a lot more concerned with bugs that have to deal with input handling than SDK bugs that developers can use to do bad things. This is likely a non-issue for those of us who haven't jailbroken our devi…

> of these bugs could be caught via static analysis which Apple obviously uses as part of its approval process.

What? Are you suggesting that OS security bugs are in fact non-issues because static analysis can detect programs that exploit these bugs?

No, it doesn't work that way. You can always encode program logic in a way that will defeat static analysis. All you have to do is write a little interpreter with PEEK, POKE, and JUMP opcodes, then encode your actual exploit logic using the little instruction set you've just created. You can make this sort of indirection as elaborate as you want, and there's no way for static analysis to see through it all. When this kind of technique is used for DRM, it takes months of expert human analysis to figure out what's going on. No way some scanner is going to do that, especially if (unlike in the DRM cracking case) there's no clear indication that there's something to discover and decode in the first place.

Post reply on HN