Live data from Hacker News

Disclosure of three 0-day iOS vulnerabilities

habr.com

431–440 of 464 posts

Re: Disclosure of three 0-day iOS vulnerabilities

#431

Earlier quoted context omitted.

GDPR cookie consent banners that make it more difficult to opt out than opt in are illegal, and only continue to exist because the GDPR is poorly and inconsistently enforced.

Cookie consent banners have nothing to do with GDPR, but with the ePrivacy directive. GDPR clarifies what is "consent", but this is not what leaded to the proliferation of cookie banners. Please note if you have strictly necessary cookies, you don't need to have cookie banners, and if your cookies are anonymous, you don't need them either ! The proliferation of cookie banners just means that people running such websi…

I routinely delete these “strictly necessary” cookies and the world doesn’t end.

Worst case scenario is I have to log in again.

Re: Disclosure of three 0-day iOS vulnerabilities

#432
post #380

Earlier quoted context omitted.

Oh, good grief, do you really need to get that pedantic? Apple made computers (devices) that ran those operating systems, and that combination mostly Just Worked (at least it did for me).

Pedantism is trotting out the fact that yeah, you can find plenty of people still running Windows-whatever on their Gateways, or lovingly cared-for TRS that still "just works". The point is that by and large, Apple devices are built in with planned obsolescence in mind (see the lawsuit they settled a few months ago about literally this).

> Apple devices are built in with planned obsolescence in mind.

They are now. They didn't used to be. My 2012 MBP is still humming right along. Earlier models were repairable and expandable and even had easily replaceable batteries.

Re: Disclosure of three 0-day iOS vulnerabilities

#433
post #264

Earlier quoted context omitted.

This seems like much more of an organisational dysfunction problem than a computer science problem. I haven’t heard anything like this about Microsoft or Google: both seem responsive and eager to fix within 90 days (mostly), have responsible browser update models (where fixes for 0 days can be pushed to the whole world within hours) instead of Apple’s irresponsible “you need a 3GB OS update even if the only fix is 3…

> instead of Apple’s irresponsible “you need a 3GB OS update even if the only fix is 3 lines of code in Safari..." Your comment seems to be implying that Apple could simply ship the delta in the source code: i.e. something like `git diff --minimal --word-diff=porcelain head^1`. Would this not require iOS to be compiled on the device, and store its own source code, à la `.git`? How would you address the issue of the c…

Those are solved problems. Chrome has being doing binary diffs for years.

The reason Apple doesn’t is because they like to ship updates as bootable disk images. This makes it easier to roll back from than an in—place update, since you can just boot the old image if the update fails.

Re: Disclosure of three 0-day iOS vulnerabilities

#434

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…

> There is indeed heart rate tracking, but can we really label this data as medical?

The detailed data (ECG level) is medical enough that devices that measure it are regulated. That’s why some features aren’t available in some countries.

Re: Disclosure of three 0-day iOS vulnerabilities

#435
post #376

Unfortunate that this researcher, shame on apple for not handling these vulnerabilities quickly. I used to believe that iphones were more secure than android and was considering making the switch. After reading this article and with some other recent news (CSAM[1], spam on the app store[2]) I don't think I'll be hopping on the iOS train anytime soon. [1]: https://www.apple.com/child-safety/ [2]:

While Apple's recent behavior does seem bad, I'm personally wondering if there is some quantitate measure comparing iOS/Android before I make the opposite switch. I wonder if iOS still may be more privacy friendly compared to alternatives regardless of the recent issue (I genuinely have no clue)

I think they're at least trying! All the vulnerabilities mentioned can be found with static analysis, which Apple is doing before accepting an app into the store. I'm pretty sure if you pack one of these 0-days in your app, it will get rejected. So as for now, this is a theoretical exercise, unless proven that this code has actually been shipped to the store.

Re: Disclosure of three 0-day iOS vulnerabilities

#436

Explain I'm naive: why would Apple's bug bounty program be so poorly run? Is it simply a sign of organizational failure? (e.g. perhaps the managers running the program have been promoted to a position that they simply don't belong in, and higher up execs don't care? Or are they prioritizing profit over success?) I would think that, given the profitability and positioning of Apple in the marketplace, that they would b…

Best explanation I've heard was in Darknet Diaries about Zero Day Brokers, which was a fantastic listen! ( https://open.spotify.com/episode/4vXyFtBk1IarDRAoXIWQFf?si=3... ) The short version is that if the bounties become too large they'll lose internal talent who can just quit to do the same thing outside the org. Another reason was that they can't offer competitive bounties for zero days because they'll be competin…

That explains the payout, but not the poor communication on the part of Apple.

Re: Disclosure of three 0-day iOS vulnerabilities

#437

Earlier quoted context omitted.

From the PoV of a security researcher - why even bother disclosing responsibly (moral obligations aside)? Best case scenario: you don't get sued into oblivion, will be ghosted and gaslightened, receive pocket change arbitrary amount of time later. Compared to that, i suppose the exploit brokers got their stuff together - after all, time is money - chances are someone else may stumble upon the same vulnerability...

If the payout is higher priority to you than the ethics of selling an exploit that governments around the world will end up using to hunt and capture or kill political dissidents, then you are of course free to sell it on the exploit market :) I prefer to sleep at night, though.

Just to clarify, since i suppose you read that wrong: i'm not a security researcher :)

Re: Disclosure of three 0-day iOS vulnerabilities

#439
post #70

Props to the author. One small critique though: > I've reported four 0-day vulnerabilities this year between March 10 and May 4, as of now three of them are still present in the latest iOS version (15.0) and one was fixed in 14.7 It would have been clearer if in each of the 4 vulnerabilities the timeline was given. The article only gives a timeline for the last vuln (the fixed one).

The second sentence of the article gives a sufficient timeline. > I've reported four 0-day vulnerabilities this year between March 10 and May 4 So the vulnerabilities were reported at least 140 days ago. He also mentions 3 upgrades of iOS were published after his reports.

Yeah, I quoted it myself. My point is that the article is formatted in a confusing way. It's formatted into 4 vulnerabilities, but only 1 of them has a timeline, which immediately made me wonder why there weren't 3 more timelines.

Even though I read the sentence at the beginning saying the author reported all 4 to Apple, when I saw there was a reporting timeline on 1 vuln but not the other 3 I started doubting my own memory and thought maybe the author only reported 1 vuln to Apple. I had to go back and re-read the first paragraph again to reassure myself that all 4 were reported to Apple.

Re: Disclosure of three 0-day iOS vulnerabilities

#440

The problem is that cybersecurity is ridiculous hard problem. The junior to senior developers are just using existing frameworks with poor documentation. Any consumer technology will be beaten to submission. It's the same never-ending war as anti-cheat vs cheat.

On anything other than trivial examples it is an impossible problem. Given the gigabyte of code on iphones (and android) it's even more impossible. Best you can do is put an emphasis on quickly fixing any issues found and to practice security hardening. It seems iphone is failing on this pretty hard currently since they didn't fix these errors that were handed to them on a silver platter.
Post reply on HN