Disclosure of three 0-day iOS vulnerabilities | Hacker News Reader

Disclosure of three 0-day iOS vulnerabilities

habr.com

2,049 pointsjayhoon456 comments

This is such an incredible amount of vulnerable mission-critical data.

- all contacts, including 3rd party messaging apps, with metadata (interactions, timestamps, other stats) - full address book - whether any app is installed - SSID of connected wifi

and formerly,

- medical info - device usage - screen time - device accessories

I don't keep anything mission critical on mobile, but this is still a gargantuan set of exploits, and each appear extremely straightforward to validate and pay out the security researcher (and maybe even patch). It's utterly tragic how Apple (and others) have devolved to become the same monolithic, careless organizations they once displaced.

I really, really hope something changes. Soon.

If these are gargantuan, how would you describe a remote zero click complete device compromise (complete with camera/microphone access)? What about an exploit that can cause the users phone to explode?

> What about an exploit that can cause the users phone to explode?

Possibly world ending, at least from the perspective of the user whose phone explodes next to their face?

I’m not saying the above issues don’t matter, but they’re hardly the most critical things you could do to an iPhone.

Do like GM, keep your phone at least 5 feet away from other phones while not in use.

You can do a lot more damage with someone's bank account than you can by exploding their phone.

Won’t matter much if it burns your house down while you’re inside.

A complete compromise can also get access to your bank, mail accounts, message history, mic and camera. Which vulnerability would you prefer be used against you?

I'd marry mic access, F#$% camera access, and kill bank access. Maybe that's just a personal opinion, though.

Depends on where the phone is at the time. Do it while they’re on a call and it’s going to really suck.

Currently holding my phone, with a full charge. Basically a hand grenade, about 12” from my face, with (thanks to oversized phones), both hands on it.

At best id be blind and unable to use my hands. I don’t give a stuff about my bank account compared with that.

There are no explosives in a phone though. Lithium batteries might burn when short circuited... however, this requires physically damaging the battery, or shorting the circuitry. This requires some seriously silly hardware vulnerabilities (lithium cell protection is typically implemented in dedicated silicon), not simply a software vulnerability. And if you could successfully perform an exploit like this, you would probably drop the phone before it hurt you.

https://youtu.be/osfgkFyq7lA?t=246

I would be an order of magnitude less concerned with camera/mic access, compared to perfect historical proof of my usage and communication patterns.

Exploits often feel like pathogens, probably why they share the term virus. If a virus has a high mortality rate, contagion is lower, because it frequently kills the host before it can spread.

Similarly, I think a 'complete device compromise' is much more likely to be identified, prioritized, and patched. The vulnerabilities mentioned here represent the highest severity without an immediately noticeable fallout. Props to the researcher.

P.S. I wonder if the researcher's Russian nationality (assumed from their other post) had any impact on their lack of payout.

It's hardly 'perfect historical proof', not to diminish the seriousness of the vulnerability. But more importantly, the mechanism matters a great deal. This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. This leaves a trace and exposes the attacker to consequences. No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it.

I’ve always been curious how many developers might drop this in their code but only activate against potentially valuable targets

I'd think also almost zero. A lot of sleazy data collection operates under at least some fig leaf pretense of user consent, in this case there's none. Once the vulnerability is discovered, Apple could find out if you've deployed such code more or less ever. Then you'd probably have problems bigger than just a contractual dispute with Apple.

Maybe some devs are allowed to do this. And that's why it wasn't patched.

> This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation.

It's a much higher bar when it's a targeted attack but not necessarily if it's a dragnet like when a malicious party buys a browser extension from the creator to harvest user data. The only real difference between the two scenarios is iOS's significantly stricter review process and sandbox - if this exploit can bypass both [1], it doesn't matter whether the malicious developer can be traced because it'll just be some indie dev who just sold his username/password and signing keys for $X0-Y00k to some shell corp in the Bahamas.

[1] Are these exploits detectable through static analysis or some other automation? (I have no idea)

The 'only real difference' is a pretty big difference - the iOS developer is much more strongly identified. It's also not the only difference - what you can do with the access is different and what you end up doing with the access is different. But in both cases, there are strong disincentives not to do very overtly malicious shit - few extension takeovers go around stealing your online banking password, even though they could.

A drive-by exploit has a lot fewer of these constraints.

Dumb implementations can be caught via static analysis. Smart ones are not going to be caught until Apple realizes they are exploiting people and reverse engineers them by hand.

To exploit this you only have to infect one of the many dependencies off user installed app. It is not true that the attacker has to forge an identity in the App Store. It is enough to insert your code somewhere along the whole software supply chain. And that can be long, think about ReactNative apps using NPM dependencies.

> No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it.

Except Facebook. Or another behemoth that felt they could weather Apple's wrath if it ever came to it. Or a company that Apple had granted special permission to do this, like they did with Uber.

Apple killed a bunch of FB's tracking a few months ago and the story is still making the rounds and is on the front page as we speak.

The point isn't that this isn't a serious vulnerability or is somehow unexploitable. It's just that there's a great deal of friction in exploiting it for relatively paltry returns. Nobody is going to get into a spat with Apple and invite regulatory and law enforcement attention to traceably and with undeniable intent steal your contact list. Nobody is going to (like another commented hypothesized) launch a supply chain attack to steal your contact list with this vuln. At that point you'd find a better vuln. This one isn't all that much better than just misleading people into giving you contact list permission.

The OP is saying it's somehow worse than drive-by or low-interaction vulns that own up entire devices and have been repeatedly found in the wild. I don't think that holds up.

Gargantuan.

> I really, really hope something changes. Soon.

I would not hold my breath... it's been like this for decades at least.

The only mitigating factor is that they’re not remote vulnerabilities.

That being said, this is more or less the industry standard. And even if the other person mentioning this was downvoted, they are right: this has been the case since forever and can only be remedied through laws making companies responsible for their failures. But neither the US government nor said companies want this. It will have to get so bad that it visibly harms US or EU security for something to move in this space.

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.

That seems a generous guess, given the mitigation of fixing the bug would be much less arduous to do and hasn't been done (for two of the exploits).

https://twitter.com/izmcm/status/1441491002259218432

The remedy for this is not just making the company's responsible for the failures, but hunting down criminals who abuse it globally and sentencing them to death.

Is that really the case? Or were they just not such a big target before when everyone was spending most of their time in a windows desktop. Maybe they just got away with it more easily in the past.

100% - they got away with it because they were small. Hacking Mac OS was unattractive - whereas, hacking iOS is the most attractive target. High gain, low security.

Apple does not have security in its DNA, as is obvious from all these exploits. Apple lives in the past where it was OK to kinda fudge it, to kinda give home apps special passes, to bypass stuff to make the game center work, and so on and so forth. These are all red flags.

Apple's threat model is script kiddies and Russian hacker groups. It's very naive vs real world exploits conducted by state level actors, companies serving state level actors, and a $1M market rate for iPhone zero day p0wn exploits.

In this cat and mouse game, the hackers are leagues ahead at this point - motivated by money and a whole different mindset.

Relying on the app store review process to catch these things is naive. A company that takes security seriously would never even think this way, obviously there's many ways around app store reviews, and hackers who went through all the trouble of finding exploits will find a way around the app store reviews, too.

Cynically I feel like we’re maybe expecting a lot here. Privacy (and I’d assume security, given it’s a necessity to achieve that) was a well-timed marketing drive at Apple, but that was months ago. You can’t expect them to support these minor features forever!

Besides, why focus on something as superficial as keeping your private data safe when the new iPhone now comes in a gorgeous pink finish. And with Ceramic Shield and the lightning-fast A15 chip? It’s truly the best iPhone they’ve ever made.

These puppies sell themselves without all that expensive privacy talk.

Honestly their attitude to the bug bounty makes me wonder if there’s not a small group of engineers that keep screaming about this problem just to have the door closed behind them and a “lol nerds” giggle heard from the execs on the other side of the door.

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 be heavily incentivized to provide large bounties for finding such destructive vulnerabilities. And I imagine that there are plenty of security people working there who genuinely care about fixing fix these issues right away.

Bug bounty programs are the antithesis of Apple's internal methodology, culture, and way of doing business. They keep everything close to the chest, they shun "outsiders", etc.. The idea that someone outside of Apple, from the unwashed masses, could find a flaw in Apple's own software is a pretty big pill for them to swallow. Thus it doesn't surprise me there are problems with their bug bounty program. I think if they could they would prefer to just silence all vulnerability/bug reports with a gag order rather than acknowledging or even investigating them.

that's just dumb, like third parties do all the work and contact you about critical bugs the only effort on Apple's part of verification and some coordination which shouldn't be a huge issue for a company the size of apple.. just hire a team to do it and be done with it the whole 'secrecy culture' is a bunch of hogwash

And yet here we are ;)

I’ve worked on the bug bounty program for a large company. We did the whole thing. It’s hard. The part you’re talking about can be the hardest.

Is probably less than believable to read because it sounds like it should be easy. I don’t have any good answers there. I’m also not suggesting that customers and researchers accept that, but saying it’s easy just diminishes the efforts of those that run good ones.

could you try litle bit harder to provide any example why it is "harder than it looks". you repeated multiple times that its hard, but what exactly(aproximately) makes it hard?

I think it's the phrases 'some coordination' and 'company the size of Apple'. It's rarely the case (well, hopefully?!) that a fix is as trivial as 'oh yeah, oops, let's delete that `leak_data()` line' - it's going to involve multiple teams and they're all going to think anything from 'nothing to do with us' to 'hm yes I can see how that happened, but what we're doing in our piece of the pie is correct/needs to be so, this will need to be handled by the [other] team'.

Not to say that people 'pass the buck' or are not taking responsibility exactly, just that teams can be insular, and they're all going to view it from the perspective of their side of the 'API', and not find a problem. (Of course with a strict actual API that couldn't be the case, but I use it here only loosely or analogously.) Someone has to coordinate them all, and ultimately probably work out (or decide somewhat arbitrarily - at least in technical terms, but perhaps on the basis of cost or complexity or politics or cetera) whose problem to make it.

What's worse, typically an exploit doesn't involve knowledge of the actual line of code responsible -- it's just a vague description of behavior or actions that leads to an exploit, making it much easier to pass the buck in terms of who is actually responsible for fixing it. The kicker is if your department/project/whatever fixes it, you're also taking responsibility for causing this error / causing this huge affront to the Apple way...

Most good exploits have a pretty solid root cause attached to them.

It's mostly just 'human factors'. What I'm describing below applies across the spectrum of bug reports from fake to huge to everything in between. Nothing of what I'm listing below is an attempt to directly explain or rationalize events in the article, it's just some context from my (anecdotal) experience.

- The security researcher community is composed of a broad spectrum of people. Most of them are amazing. However, there is a portion of complete assholes. They send in lazy work, claim bugs like scalps and get super aggressive privately and publicly if things don't go their way or bugs don't get fixed fast enough or someone questions their claims (particularly about severity). This grates on everybody in the chain from the triagers to the product engineers.

- Some bounty programs are horribly run. They drop the ball constantly, ignore reports, drag fixes out for months and months, undercut severity...all of which impact payout to the researcher. These stories get a lot of traction in the community, diminishing trust in the model and exacerbating the previous point because nobody wants to be had.

- Bug bounties create financial incentives to report bugs, which means that you get a lot of bullshit reports to wade through and catastrophization of even the smallest issues. (Check out @CluelessSec aka BugBountyKing on twitter for parodies but kind of not) This reduces SnR and allows actual major issues to sit around because at first glance they aren't always distinguishable from garbage.

- In large orgs, bug bounties are typically run through the infosec and/or risk part of the organization. Their interface to the affected product teams is going to generally be through product owners and/or existing vulnerability reporting mechanisms. Sometimes this is complicated by subsidiary relationships and/or outsourced development. In any case, these bugs will enter the pool of broader security bugs that have been identified through internal scanning tools, security assessments, pen tests and other reports. Just because someone reported them from the outside doesn't mean they get moved to the top of the priority heap.

- Again in most cases, product owns the bug. Which means that even though it has been triaged, the product team generally still has a lot of discretion about what to do with it. If its a major issue and the product team stalls then you end up with major escalations through EVP/legal channels. These conversations can get heated.

- The bugs themselves often lack context and are randomly distributed through the codebase. Most of the time the development teams are busy cranking out new features, burning down tech debt or otherwise have their focus directed to specific parts of the product. They are used to getting things like static analysis reports saying 'hey commit you just sent through could have a sql injection' and fixing it without skipping a beat (or more likely showing its a false positive). When bug reports come in from the outside, the code underlying the issue may have not been touched for literally years, the teams that built it could be gone, and it could be slated for replacement in the next quarter.

- Some of the bugs people find are actually hard to solve and/or the people in the product teams don't fully understand the mechanism of action and put in place basic countermeasures that are easily defeated. This exacerbates the problem, especially if there's an asshole researcher on the other end of the line that just goes out and immediately starts dunking on them on social media.

- Most bugs are just simple human error and the teams surrounding the person that did the commit are going to typically want to come to their defense just out of camaraderie and empathy. This is going to have a net chilling effect on barn burners that come through because people don't want to burn their buddies at the stake.

All of this to say it takes a lot of culture tending and diplomacy on the part of the bounty runners to manage these factors while trying to make sure each side lives up to their end of the bargain. Most of running a bounty is administrative and applied technical security skills, this part is not...which is why I said it can be the hardest.

Reading the OA, I also believe that there's a wide variety of technical detail that could be the cause of, say, not responding.

Maybe the reports get to the tech teams, the tech team figures out that this bug will definitely be caught by the static analyzer, and they have other more pressing issues.

The main problem today IMO is that the incentives for finding and actively using exploits are much higher than the incentives for fixing them, and certainly much higher than building secure code that doesn't have the issues in the first place.

After all, nobody will give you a medal for delivering secure code. They will give you a medal for delivering a feature fast.

I’ve been in infosec since the 90’s, moving slowly has killed way more companies than any security issues.

I’ve worked at some of the largest financial institutions and they spend billions on security every year to achieve something slightly better than average. Building products with a step function increase in security would incur costs in time and energy and flexibility that very few would be willing to pay.

Apple is all about silos.

So a security threat gets reported to this bug bounty team. They are able to reproduce and confirm. The bug is in some deep, crusty part of the kernel; the code for which isn't available to this team, because Silos.

The team who does have access to this Silo is tracked down. It gets processed into a ticket. Maybe it gets done, maybe it doesn't. Their backlog is already maxed out, as is everyone's.

The security team says "we've done all we can".

This is not a matter of "lol just hire a team". You need leadership aligned, so the manager's manager can see their task list, or open security issues, and say "what the fuck, why are you not prioritizing this".

That's not Apple. Apple is product-driven. They actually, legitimately don't care about Privacy and Security. Their manager-managers get mad when products aren't delivered on time. They may also push-back on purposeful anti-privacy decisions. Its not in their culture to push back on Security issues, or latent Privacy issues resulting from those Security issues.

"Just tear down the silos" > Working for Apple is a cult. The silos are a part of the cult; left-over from one of the worst corporate leaders of all time, Jobs. Try telling a cult member their beliefs are false.

"Grant the security team access to everything" > And, I guess, also hire the smartest humans to ever exist on the planet to be able to implement security improvements across thousands of repositories in dozens of programming languages, billions of lines of code? And, even if they could, push those changes through a drive-by review and deployment with a team on the other side of the planet you've never met? You, coming into their house, and effectively saying "y'all are incompetent, this is insecure, merge this" (jeeze ok, we'll get to it, maybe in... iOS 18)

Accurate - Engineering at Apple has no tradition of security; nor does it have a tradition of being very efficient. It's mostly based on heroics of some very few very talented developers. Processes that are in place are actively hindering development.

Scaling development is hard, and Apple has never really gotten it right. I am wondering if a zero day is $1M on the open market - wouldn't it be easier and cheaper to get an engineer inside Apple to leave some plausible deniability bugs in the code? Or compromise an engineer already there?

Software engineering never had security as its main goal - but today, if you had to do it all over, security would be built into all processes from the get go, and that's likely the only way software could be made secure.

It always amazes me Apple (and others) can't even make a browser that doesn't have a drive by zero day that can take over my computer. Why is that? There must be something fundamentally wrong in the system here. And I think what's wrong is that security was not even in the minds of engineers when most of these software modules were created.

BSD had it built in, but they watered it down instead of - what they should have done - doubling down on it.

That makes apple (the org, not the fanboys) sound a bit cultish... Can't say I'm surprised though...

It is cultish.

It is in SV after all..

There are plenty of companies in SV that are the opposite of cultish, eg. Google is known to try to be more like a university. (or it was at least, I think they are pulling back on that as their political problems mount.)

This is not my experience with google. It’s a bit cultish; “googliness” meaning “being good and helping” is one of many examples of this cult.

There are entire books that romanticise the cult aspect of working at Apple.

Disclaimer: I am not an Apple insider by any means, and this is all a hypothesis.

Their management of the bug bounty program seems like a reflection of their secretive (and perhaps sometimes siloed) internal culture. I'd argue that for any bug bounty program to be successful, there needs to be an inherent level of trust and very transparent lines of communication - seeing as though Apple lacks it internally (based on what I've read in reporting about the firm) it is not particularly surprising that their program happens to be run in the shadows as the OP describes.

I forget the exact term for it, but there is a "law" in management which postulates that the internal communication structures of teams are reflected in the final product that is shipped. The Apple bug bounty seems to be an example of just that.

Edit: Its called Conway's Law

Apple has always been infamously bad at doing anything with external bug reports. Radar is a black hole that is indistinguishable from submitting bug reports to /dev/null unless you have a backchannel contact who can ensure that the right person sees the report.

Bug bounty programs are significantly more difficult to run than a normal bug reporting service, so the fact that they're so bad at handling the easy case makes it no surprise that they're terrible at handling security bugs too.

I actually got response for a bug report saying "We fixed that, can you try it on the next beta and send as a code sample to reproduce it if the bug is still there". But that bug was about the way SwiftUI draws the UI.

I used to submit bug reports for things I found in macOS or any other applications, like that Pages would include a huge picture in the files for no reason at all. But those bug reports would usually be closed and "linked" to another bug report you don't have access to. Essentially shutting you out. At some point you just give up. At some point bugs are getting fixed but there is no pattern to it.

It's interesting to me that in this entire thread, nobody is even mentioning or considering the possibility that COVID has impacted Apple's operations.

It obviously has. It has affected every tech company. Certainly it has affected mine. Whether this is an example of that, I don't know, of course, but I think it's plausible.

So what? Everyone has been affected. Apple doesn't somehow get a pass at not doing their basic duties.

Sitting at home looking at a monitor and typing is largely the same doing the same thing in an office. They're not service sector workers, doctors, nurses, or truck drivers who actually have had to deal with the impact of this head on.

I see no reason COVID has anything to do with Apple’s poor response to external reporters, which has been something that has been a problem for decades.

I'm curious. Would you accept it if Apple came out and said that the reason this is happening is because of the COVID pandemic affecting their operations?

Surely even if it were true, that is no excuse for a company like Apple?

Did I say I "accept" it? No.

Did I say it was an "excuse"? No.

Please don't put words in my mouth. The -4 downvotes made your point well enough. I get it: people want to trash Apple by any means necessary and that's way more important than a free and open discussion of the issue. Thanks.

Your reaction to my comment is quite unfair.

After claiming that I am putting words in your mouth, you go ahead and accuse me of only wanting to trash Apple and not caring about having a discussion.

I would have preferred it if you had simply told me to fuck off.

Apple could have chosen to simply not release a new iPhone or iOS version this year, if it wanted to. To the extent that they prioritized that over fixing up their security infra, that's on them.

Hackers aren't going to stop because of COVID. Apple has a duty to their customers to keep their products secure.

> Explain I'm naive: why would Apple's bug bounty program be so poorly run?

Hubris.

Apple's culture is still fundamentally the same from the day they ran ads saying "Macs don't get viruses" to today. They used a misleading ad copy to convince people they could just buy a Mac and be safe, not needing to do anything else... ignoring that Macs still got malware in the form of trojans, botnets and such... and encouraging a culture of ignorance that persists to this day. "It just works." etc.

So now their primary user base is majorly people who have zero safe online habits.

And that sort of mentality feeds back into the culture of the company... "Oh, we're not Windows, we don't get viruses. We don't get viruses because our security is good. Our security is good, obviously, because we don't get viruses." It, in effect, is a feedback loop of complacency and hubris. (A prime example of this is how Macs within the Cupertino campus were infected with the Flashback botnet.)

Since their culture was that of security by obscurity (unlike, say, Google's explicit design in keeping Chrome sandboxed and containered for sites), closed source and again, hubris... it's coming back to bite Apple in the ass despite their ongoing "We don't get viruses" style smugness. If it's not about Macs not getting viruses, it's about how Apple values your privacy (implying others explicitly don't) and like with everything else, it's repeated often enough to where the kool aid from within becomes the truth.

Apple's culture is that of smugness, ignorance and yep... hubris. Why should they have a serious, respectable bug bounty program if they've been busy telling themselves that they don't simply have these kinds of security problems that they've bragged about never having?

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 coherent at first glance but are often nonsense or not really a vuln at all, and of course there are many duplicates or near duplicates.

If each of these takes 20 mins to triage, 1 hour to properly look at and days to confirm, you can see how a team of any reasonable size would soon be completely submerged and unable to respond to anything but the most severe and succinct vulnerability reports in a timely way.

I feel like Apple could afford to staff a security program like this. Much, much smaller and less wealthy companies manage it.

much smaller, less wealthy companies attract far fewer reports

I don't buy this. They fixed one reported, got back to him and acknowledge the lack of disclosure, apologised, promised to fix it and never actually disclosed it 3 reports later.

It's not a case of "someone missed this" it's "this seems dysfunctional".

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

I think they don’t want to admit such a big security breach publicly. At some extent privacy is their business.

Here's my totally outsider informed guesswork. We've seen similar problems recently with Microsoft, where legitimate sounding issues are denied bounties, so this kind of issue is not unique to Apple.

My guess would be, that MSRC and Apple's equivalent have an OKR about keeping bounties under a certain level. Security is seen as a cost centre by most companies, and what do "well run" companies do with cost centres... they minimize them :)

I don't think that organizationally either company wants to have bad security, and I don't think that individual staff in those companies want to have bad security, but I do think that incentive structures have been set-up in a way that leads to this kind of problem.

I've seen this described as lack of resources in the affected teams, but realistically these companies have effectively limitless resources, it's that they're not assigning them to these areas.

> My guess would be, that MSRC and Apple's equivalent have an OKR about keeping bounties under a certain level. Security is seen as a cost centre by most companies, and what do "well run" companies do with cost centres... they minimize them :)

It would have to be this.

If you start to increase the payout, you get more people wanting the payout.

Apple does not have cost and profit centers. They maintain a single profit and loss balance sheet for the entire company.

That doesn't mean the functional areas don't have a budget or resource constraints, but Apple's structure is quite different from most companies.

I'd agree with the other comments that pin Apple's specific issues on their insular culture that discourages all forms of external communication if you're not part of marketing. Great bug bountry programs require good communication with researchers and some level of transparency, two things apple is structured to avoid and discourage.

My hypothesis is a lot simpler:

Hacking is much more profitable than preventing hacking.

Incentives are heavily biased towards security exploits on all levels.

End of story.

There's no reward for "your code never got hacked". There's a reward for delivering a feature in time and a penalty for not doing so.

You'll get a bonus or promotion for delivering features. If you take twice as long because you made your code really secure - no one will know.

I think that's really all there is to it. Security is obscure and complicated.

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 competing with nation states, effectively a bottomless bank, so price will always go up.

I don't know much about this topic, but surely there are some well structured bounty programs Apple could copy to find a happy middle ground to reward the white hats.

this is the real reason. not anything internal/culture related

A good iOS 0-day is worth hundreds of millions of dollars in contracts with shady governments. Apple can't compete with that multiple times a year

According to Zerodium, iOS exploits are cheaper than Android exploits because they are so plentiful in comparison.

This doesn't compute: is the claim Apple badly manages its bug-bounty because 0-days are too valuable? If that's the case, I'd expect the opposite effect: Apple would recognize how valuable the reports being sent to them by white-hats are, and would react with a sense of urgency and gratitude. As it is, Apple is behaving as if 0-days are worth very little, and not a big priority.

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

It doesn’t matter how big of a company they are, the only thing that matters financially is whether they’re growing or not.

Its company culture, some companies see failure as a problem to be avoided others see failure as the road to success.

Evidently apple see failures like bugs as a problem to be avoided and are just trying to avoid the problem with the obvious result that they have problems and look like a failure.

Companies that accept failure as a consequence of trying will learn and improve until they achieve success.

Having worked in at a large tech company with a big bug bounty program and seeing tonnes of bugs come through, my experience is that usually there is a wide disconnect between the bug bounty program (situated in one org of the company) and the engineering group responsible for fixing the bug (which is in a different part of the company.) This is exacerbated by misaligned incentives, bug bounty team wants fixes ASAP while PMs/TPMs dont care about security and want engineers to be busy on feature development vs fixing bugs. On top of that if the leader of that org comes from a non-tech background then its even harder to convince them to prioritize security. Bug bounty teams are mostly powerless pawns in the politics between leaders of several different orgs with varying cultures of caring about security.

This is roughly how I have seen things work internally:

* When a bug report comes in, the bug bounty triage team tries their best to triage the bug and if legit, passes it on to the infosec team situated within the organization where the bug belongs.

* Security team for the org then scrambles to figure out which exact team the bug belongs to assigns it to them.

* A day or two later that team picks up the bug and there is usual back forth on ownership, "oh, this is that part which this another team wrote and no one from that time now works at the company" or "its not us, its another team, please reassign."

* Even when the right team is assigned to the bug, there are discussions about priority and severity - "oh we dont think its a high sev issue" types of discussions with PMs who have no knowledge about security.

* Even when everything gets aligned, sometimes the fix is so complicated that it cant be fixed within SLA. In the meantime, security researchers threaten to go public, throws tantrums on Twitter while Bug bounty chases internal teams for a fix.

* When the bug cannot be fixed within SLA, the engineering folks file for an exception. This then gets escalated to a senior leader who needs to approve an exception with agreement from a leader within security. This takes a couple of days to weeks and in the meantime, security researcher has now completely lost it because they think no one is paying attention to this crazy oh so critical bug they spent day and night working on.

* When exception is granted, bug bounty swallows the pill and tries to make up excuses on why it cant be fixed soon. Eventually, 90days are over and researcher feels disrespected and establishes animosity and starts to think everyone on the other side a complete idiot.

* A blog shows up on HN and gets picked up by infosec twitter and slowly media catches up. Now, internally everyone scrambles to figure out what to do. Bug bounty team says "we told you so" and engineering team figures out a magical quick band-aid solution that stops the bleeding and partially fixes the bug.

it feels like we're conflating two issues here: fixing the bug on time and paying out the researcher. at the point where the bug is too complicated to fix within SLA and the exception has been escalated to senior leadership, surely the bug bounty team can pay the researcher?

That honestly sounds like a failure to communicate with the researcher first and foremost. If it's difficult to prioritize the fix internally due to organizational politics, that's one thing, but that shouldn't stop the bounty team from communicating the status to the researcher. In fact, that should be the simplest part of the whole process, as it's completely within the purview of the bug bounty team. If they handle that right and build some trust, they might be able to successfully ask the researcher for an extension on disclosure.

Case in point, Apple likely could have come out of this looking much better if they didn't ignore and then actively lie to illusionofchaos. That really isn't a very high bar to clear.

Apple didn't get rich by writing a lot of checks

ironically, spoken by Gates @0:52 https://www.youtube.com/watch?v=H27rfr59RiE

If your annual revenue is above $100M, you should be held accountable to a strict version of GPDR enforced by an ombudsman, that requires you to patch all data leaking vulnerabilities within 90 days, or pay out everyone who bought your product.

I just updated to iOS 15 and it now tells you which sites you have been compromised on, or had your passwords/info compromised on. To be clear, I use a password manager with a unique password on every site, so it is difficult for something like this to have a significant impact. Nethertheless, I was compromised on hundreds of sites and products, and those were just the accounts that iOS Safari knew about. None of them bothered to reach out and tell me. Even my coffee machine was compromised. Ridiculous.

God, I would HATE if the US follows the EU with this craziness. I'm already sick of the cookie popups, now layer on the GDPR insanity and we will definitely lose the privacy fight to users who will be sick of this nonsense as well.

I've seen studies that show crap like GDPR (which makes basically all normal interaction cumbersome) has like 10% of folks clicking around to "opt-out" while 90% can't be bothered. And of course, you COULD just clear your own cookies.

There is no more real security in the EU. Your mental health records will be leaked there. The EU will spy on you like crazy. And more.

Is there a point to this...? Or did you just want to crap on GDPR?

Not saying it's good or bad. But just...relevance?

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.

Most of the cookie consent banners I see are illegal in that case..

That's right.

And how many have you reported to your local data commissioner?

That's the point. GDPR without good enforcement is useless and meaningless. I'd even argue that all this time since GDPR and until something is done about enforcement if ever (that is not just a random fine, which is considered cost of doing business) all that GDPR is doing is allowing these companies to come up with more elaborate ways to scam (I'm looking at whoever the assholes who work, run, or are remotely involved with trustarc.com).

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 websites are usually terrible with regards to consent, personally identifiable information, and so on.

Non-essential cookies are personal data as regulated by the GDPR. It is true the EPD started the cookie consent popup craze though.

Finally, at least one person in this thread who understands that GDPR is not cookie banners. I mean WTF, we're on hacker news. Oh wait, yeah, we're on hacker news.

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

Worst case scenario is I have to log in again.

Correct. The vast majority of such cookie banners you see are illegal according to the GDPR, i.e. whenever you see one that doesn't have equal prominent "Accept"/"Reject" options next to each other.

The only reason these illegal banners still get used is a lack of enforcement. Right now, the enforcement process is rather slow, which is in part due to all this stuff being "new" (the cookie ePrivacy is technically from 2009 already, but regulatory bodies with a clear focused mandate to enforce infractions only really came into existence with the GDPR) and thus regulatory bodies and sometimes courts still trying to figure out the legal details, and acting slow and (overly) cautious in order not to embarrass themselves by issuing fines that are later thrown out in a high court. (And then there is Ireland...). And more generally, the law is rather slow regardless; the time it takes to conclude any "important" case is measured in years, and sometimes decades.

There are civil organizations such as noyb[1] trying to get things going and "nudge" regulators into action, but even with that it will be a few more years at least until the legal questions around "what is an acceptable cookie banner" are settled.

[1] https://noyb.eu/en/noyb-aims-end-cookie-banner-terror-and-is...

> crap like GDPR (which makes basically all normal interaction cumbersome)

Only if you count "tracking users on first visit before they do anything else" as normal. Otherwise, there isn't a banner needed; sites could simply have a link to opt-in to tracking in the header or footer, and not track unless the user opts in.

This is like passing a law making it illegal to just hit people in the street, requiring you have to ask them for consent first. So most of the people who want to hit others up come up with some gish gallop that most people fall for, and then hit them.

And people bitch about the law, and claim it "makes it necessary for people to chew off the ear of other people they pass by in the streets"... with a straight face, that's what they twist it into, with an air of indignation even... and not just for a few weeks, until they read up and the initial misunderstandings are cleared up, but year in and year out, because they never read up, and the falsehoods you just posted keep getting repeated.

>> crap like GDPR (which makes basically all normal interaction cumbersome)

GDPR do make a lot of things cumbersome, not only if you are doing "bad" things.

Remember that GDPR covers information gathered and stored on paper as well. And it covers not only companies but also organisations, like children's soccer clubs.

So let's say you have a printed list where kids and their parents signup with name and phone numbers, you should probably have a data integrity policy and someone akin to a DPO. In your small non-profit soccer club!

(My problem with GDPR is that it doesn't really, at least so far, hinder the worst trackers, but incur large cost all across society, even where handling personal data isn't really a problem)

> GDPR do make a lot of things cumbersome, not only if you are doing "bad" things.

That's a far cry from "they make these cookie banners necessary". Tracking people without consent on first visit is what makes them necessary. The anger is consistently misdirected at the people who violate the boundaries of others, not the law that requires consent for it.

> So let's say you have a printed list where kids and their parents signup with name and phone numbers, you should probably have a data integrity policy and someone akin to a DPO. In your small non-profit soccer club!

"We'll ask them if it's okay to store it, and once they leave the club we delete their contact information after N months." Now you have a policy. The person who does everything else, the person who is already secretary, receptionist, accountant, project manager, janitor, coach, counselor, CEO, is now also the PDO.

Human rights being trampled on with an ever increasing mesh of surveillance by big agencies and corporations as well as little informants are such gross violations, such a terrible trajectory we put society on, that mere complication and discomfort is not something that can ever trump them in my book. I would even say if you can't put food on the table without ignoring the human rights of others, just don't put food on the table -- because that's the negotiable part, while the preservation of human rights is not. We need human righs, we don't need ad-hoc low-effort soccer clubs. Like, at all. Just get a ball and some friends in that case.

Yes! You should!

This is the same as if your small, non-profit club deals with dangerous chemicals - it needs to make sure that the appropriate risk assessments are done, and safety information is available to users. Or any club dealing with children - it may need to make sure that the people have an appropriate background check.

Likewise, holding personal data is a risk to the people whose data is held. If you want to hold on to that data, your responsibility should include making sure that it is stored and used safely. If you don’t want to pay that cost, then stop holding it.

Your view is of course fully valid, and probably the view reflected in the GDPR legislation.

To use your metaphor of chemicals:

I see the current situation as if the soccer club is handling a 1L container of consumer-grade vinegar weedkiller, and is required to do pretty cumbersome things to document their use and keep it "safe". Many of them have consulted some firm or expert to get boiler-plate documentation, because even if fines are unlikely they are anxious about them.

At the same time, we have enormous commercial actors that handle millions of liters of radioactive wastewater in rusty containers. These companies have, for sure, spent a lot of money on "compliance". Some small improvements have surely been made, but the fundamental business practice among these actors of handling radioactive wastewater have not changed. Some "large" fines have been given, but they barley make a dent in the enormous profitability of handling these toxic things.

At least not yet, 3 years in. Maybe it will change in the future, and the big actors will fundamentally change their behaviour.

If that happens, I can agree that the weedkiller documentation is worth the cost, but so far I'm sceptical.

(Since this is an Apple thread, I think its interesting to compare the _real_ privacy gain of GDPR as a whole, vs Apple's simple tracking-popup)

> I see the current situation as if the soccer club is handling a 1L container of consumer-grade vinegar weedkiller

What if one of the kids' parents is on a protection program? What if two years later you find to have the contacts details of a famous star/politician/CEO? What if one of the people on your lists gets in a controversy and you happen to have certain proof of events? And so on.

I'm trying to argue how apparently innocent data might very well be highly sensitive instead, but that without a proper framework to assess that, you never know.

What’s the incentive for a user to opt-in to tracking?

I mean, isn't that kind of the point?

Some people claim that they want personalized ads (at least on HN and similar communities)

I've never met anyone in real life who wasn't creeped out by a targeted ad. Everyone nowadays has a story about how they were having a conversation with someone about something, and then one of their devices served them an advertisement for the thing they were talking about.

Everyone finds that creepy as hell, but it's hard to attribute it to any particular device/company, and even if you find out that it's your Alexa that's spying on you, it's hard to throw it out. Not only is it a waste of money, it's a loss of a convenience, and there's some social pressure involved. Like do you really want to be seen as that one paranoid weirdo who doesn't trust technology that everyone else is using?

Alexa... well you paid for this device to spy on you so that definitely should not surprise anyone.

I think it's bizarre that people are not only OK with having their house bugged with a device that listens to their every conversation - but they're happy to pay for the privilege.

Do you know that when you have an argument with your partner, Alexa is listening to the whole thing? Sensitive business meetings... etc... very strange!

You cannot claim that GDPR is a good law, not with the galaxy-sized loophole where you can track the vast majority of people just like before, as long as your annoy them first.

Better than nothing, sure, but not good.

I didn't say it's perfect, but it's surely better than it's presented by people who get nothing about it right.

The GDPR explicitly disallows "annoying" users into granting consent. Here are the ICO guidelines about it: https://ico.org.uk/for-organisations/guide-to-data-protectio...

If you annoy users into clicking "accept" then you are in breach and may as well just track users without asking at all.

The only reason for the GDPR is to get more government control on your daily interactions.

People are out of their mind to think that governments are working to "protect" them - hello? Govern ment means to rule the mind, mind control, that's the word, and the main mind control governments are interested in perpetuating is to make you believe you need them.

If people didn't think they need their government, there would be no more governments - and they couldn't control us.

Logically, if I was the government, I would mainly work on making sure that people think they need me. I would have every incentive to create catastrophes, pandemics, wars, in fact I would have every incentive to create any problem that has, as its solution, more governmental control.

The only interactions made cumbersome by GDPR are those with organizations that abuse their users/customers’ data.

Otherwise you don’t even need a cookie banner.

So, all of them.

Doesn't mean the law is bad.

Given that, is the law bad, or is the default behavior of companies?

The cookie popup is something else, and the result of misinterpreted legislation and companies trying to cry foul that they can't do whatever they want anymore. It's not at all needed for common cookie usage - just the unexpected soul-selling kind.

GDPR restricts companies from using data however they want, makes you able to obtain a copy, and makes you able to require it deleted. It also required the company to document, provide a person responsible to contact, etc.

It only benefits you as a consumer, and the downside in proper uses is that the webpage/app might have a page somewhere with data processing information should you be curious. Nothing major.

Any nuisance are poor implementations or because companies can no longer do terrible unexpected things, like selling your data to hundreds of companies just by accessing a page, without permission, because it is nonsense no one would expect or want.

And with everyone clicking "no" (which must be at least as easy as clicking "yes" as determined in court), the practice would die eventually.

Hang on, you have a coffee machine that is capable of being compromised? How exactly?

Further to this, you claim that you have been compromised on HUNDREDS of sites even though you use a unique password everywhere?

How is this happening to you? Isn't this a huge concern?

Right, it’s hard to compromise a kettle and manual grinder, the only thing I could possibly consider a benefit of a networked coffee machine is you can schedule it/script it with home assistant.

But even then, I’m pretty sure you can buy simple electric ones with timers…

Only if it is HTCPCP(-TEA) compatible. Otherwise they should not bother.

/s, since it is not the specialized coffee machine on the office floor which is the biggest problem but the thousands of ones at home where people do not even bother to firewall it.

When I was looking for an espresso making a lot of them have touch screens and connected features. They will wake up before you get out of bed and have hot water ready. I specifically bought one without touch screens and all that crap. It takes maybe 30 seconds for the water to heat up.

Lots of people will get their regular coffee maker ready the night before with water and ground beans. At a specific time in the AM it will brew. Lots of old models have timers you can set. I avoid smart devices like the plague. My Bosch fridge is a smart fridge and I plan on putting it on a VLAN.

>My Bosch fridge is a smart fridge and I plan on putting it on a VLAN.

As another new owner of a Bosch fridge, why put it on anything at all? I just peeled the sticker that told me how to connect off, threw it in the trash, and treat it just like my old non-connected fridge. Is there actually some beneficial feature that makes it worth connecting at all?

The right french door is hard to close compared to our last side by side fridge. For now it helps me remember to close it when I’m in a different room and can’t hear the alarm.

That is hilarious.

Problem: Right french door is hard to close and user often leaves it open. User does not hear alarm.

Solution 1: Make french door easier to close / close automatically.

Solution 2: Make alarm louder. Adjustable even.

Solution 3: Add networked computer, software, mobile phone application, and wire them all up.

It’s caused issues with my wife thinking the kids milk has gone bad because the door was ajar. Trust me when I say peace of mind and possibly getting hacked is much better than an angry wife plus hungry kids.

French door fridges have this flat piece that slides behind one of the doors to make it airtight. Our previous place had a Samsung that did the same thing, except it was the left door and easier to shut.

It’s made by Germans, they don’t always make things usable or even serviceable (German cars).

I apologize, I did not mean to disparage your solution for a purchase you already made. I was cynically imagining the thinking of the manufacturer! Also, yes, we have a fridge with french doors, so I understand the problem. Ours just has a really effective alarm. Have you tried sticking two small wedges under the front feet so that the doors get a little more momentum when swung closed? That was actually in our manual. (Yes I read my fridge's manual).

Funny. My only problem with the door has been that it sometimes closes half or two thirds of the way. It's clearly partly open and presumably leaking cold air, but it's closed far enough that the audible alarm doesn't activate.

> Further to this, you claim that you have been compromised on HUNDREDS of sites even though you use a unique password everywhere?

It’s not too far-fetched.

I’ve been compromised on dozens of sites out of ~1.500 sites on which I have accounts, all of them with unique email addresses and unique passwords. Those dozens accounts are just those I happen to know about (through HIBP, incoming email spam, or the occasional site owner’s disclosure) so they’re probably just the tip of the iceberg.

Sites are being breached left and right. If you’re lucky, the site owner tells you. Many won’t.

Aren't Ombuds generally limited to investigations and recommendations (not enforcement)? What country colors your context? (e.g. I'm in the US where federal Ombuds aren't much of a thing, though similar roles may be filled by other persons).

This is crazy. At this point it's pretty well established that Apple isn't really going to pay you much if at all. Might as well disclose in 90 days at this point.

Full disclosure is always responsible, even if the vendor is not notified in advance.

This is a part of our industry I do not follow beyond headlines. A lot of those headlines are about hackers trying to be responsible getting screwed out of supposed bounties that to my mind already appear quite small. Also responsible companies doing very little to quickly close them. Does anyone have any insight into how the market for vulnerabilities operates? Is there is a significant disparity in price between official/responsible disclosures and private sales?

Private buyers almost certainly pay a higher amount and their payments arrive much sooner.

Apple's published rates are high (up to $1M), but in practice they pay a lot lower.

So most public companies don't even run bug bounties. The ones that do may or may not acknowledge your disclosure, and they decide what your vulnerabilities are worth regardless of any scales they might post on a blog. So in a best case scenario, you get maybe 10-100k for a world ending RCE + escalation but most of the time you get no response or <1k. On the gray market, though, something like that will easily sell for over 100k, sometimes several million. Generally it's frowned upon in academic circles, but there are a handful of large brokers like zerodium who are happy to pay out for interesting bugs.

Zerodium is not interested in this kind of bugs. If they own at least one RCE+LPE, they can already access all data on any device and more

As someone that actively works in the security industry and has spent quite a bit of time tracking this... Yes, there is a massive disconnect in pricing for private acquisitions of vulnerabilities in commonly used software.

Almost always it's between a 2-5 magnitude order of difference in price between a bug bounty and what a company like Zerodium pays. When they have a valuable enough customer asking for something specific they'll even give bonus rates between 2x-10x above their normal rates.

Here have a tweet where Zerodium is doing exactly that: https://twitter.com/Zerodium/status/1437884808257024008

Do you know of anyone personally who was paid?

Oh sure, Zerodium pays (over time, as long as bug is unpatched), if you don't care how your exploits are used (will it be used to target middle east journalists or jeopardize our democracies by watching over elected representatives? who knows.); sure, they vet their customers, and the customers swear they won't do anything bad with it.

Note: not sure they would pay for these private information leaks. They'd probably prefer a local escalation and then do the data collection themselves.

Holy fuck what kind of turds are these? Their "temporary" bounty boost listing includes specifically Moodle.

That's an application that will be used by minors to a large extent, meaning they're literally leaving kids the world around unsafe.

How any of this can be legal is beyond me.

Btw they're also targeting pidgin, I'm imagining this might be related to OTR sessions over tor...?

Edit: remembered moodle is used by universities as well, so not overwhelminly but still....

Edit 2: IMHO working or having worked for one of these companies should be a career ending move. Simply not acceptable to be working in this field anymore. Not by legal means of course, but as an industry we should simply consider people who were willing to sign a contract with these criminals to be unemployable. "Sorry we don't do business with turds."

>as an industry we should simply consider people who were willing to sign a contract with these criminals to be unemployable.

By that same logic we coul include mass ad/surveillance companies like Google and Facebook to the list. IMHO those do way more damage to society as a whole. Where do we draw the line?

The fact that drawing any specific line is always wrong to an extent, and that it is difficult, is not a good argument against drawing a line at all.

We have tons of jobs you're even legally not allowed to do, no matter how profitable. We're literally talking about people who deal in vulnerabilities in software used by minors, with the express intent of keeping these open.

In my book, that is beyond the line. Change my mind.

Interesting to note: these exploits aren't caused by memory safety, like a lot of other Apple exploits, but by plain API abuse and bad design.

that's why these were "Wontfix: Working Poorly as Designed" :^)

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)

IMO, that seems like apple but the lines are getting closer than ever

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.

It can be shipped, static analysis is easily bypassed, you can check it yourself on gamed exploit

Isn't this why most researchers just sell their 0days to Zerodium or drop it publicly? I've heard of multiple companies doing this type of BS. There was a person called Polarbear/sandboxescaper who dropped a few Win10 LPE's on GitHub. They claimed that Zerodium also only pays out a small amount then resells the exploit.

Yes, that person did drop 0days publicly and then promptly faced an FBI investigation causing a tremendous level of stress and irreparable mental health damage.

It looks like that they no longer work for Microsoft anymore. Weren't they making some not so great comments before the FBI investigation though?

She said all kinds of things that would trigger investigations, everything from threatening the president to searching for foreign state hackers to attack the US with her.

Surprisingly MSFT still hired her after this

She faced a FBI investigation over the threats she was making during her rants, not because she dropped 0days publicly. It is not very cool of you to falsely insinuate that these things are related.

There aren't worth anything to Zerodium afaik

Maybe they would've been to ZDI.

With such a successful privacy marketing campaign, Apple doesn't really need to care about security anymore to make boatloads of money. The public is mislead into thinking iPhones are secure and news outlets won't report on these minutiae.

With these Apple-related vulnerability annoucements on HN, usually we see response from a satisified Apple owner along the lines of "This is fixed in [some new version number]". The thing is, the problem isnt whether something is fixed, its that it was broken to begin with. It passed "QA" at a trillion dollar company and its a pre-installed fixture^1 on some relatively expensive hardware item. If there is such an "it's fixed" response, it usually rises to the top comment. The underlying message seems to be, "No worries. You can safely forget about this and keep loving Apple hardware running the crappy but user-friendly, irremovable (work-in-progress) software that comes pre-installed on it."

How long till this "It's fixed" comment appears. Might come in a different submission. For some folks, Apple can do no wrong. No amount of truth can change their views. The only issue to these folks is "fixing"; they are content to use software that is a WIP but marketed as ready for primetime and to dismiss any ideas about using software that is considered finished.

The best place for important data is external media not a "smart" phone running an OS and software that the user does not have control over. "Everyone else is doing it" doesnt transform a stupid practice into a smart one, it just means no one will criticise the choice. That of course also opens the door for those following the herd to attack anyone who dares to suggest deviating from the mainstream because "how can the majority of people be wrong".

1 The purchaser cannot remove it and install their own replacement.

That would be a nice problem to have.

No, the issue is despite disclosure two of them still aren't fixed.

Consider also time of introduction (of the vulnerability) to time of patch.

We have now seen bugs that have been around for 4-5 years before being discovered by ethical hackers and subsequently patched.

No os/mobile platform is free of security bugs. No amount of “QA” will be enough. Just look at the number of vulnerabilities literally any OS has, or even any component such as Chrome or Safari.

It is a shame that the author didn’t get replies in time and felt the need to disclose. I’m sure it’ll at least get quickly patched now.

The only bug-less software is software that was never written.

Please point me to a consumer OS that doesn't have security vulnerabilities.

The joke here is that they advertise security.

This is their main claim atm.

I can advertise that I sell a lock that hasn’t been picked or bypassed. That doesn’t mean it’ll never be picked.

Good on you. I'd be happy to make a small contribution to your legal fund if Apple tries to send lawyers after you. Even if these vulns weren't critical there's no excuse for their inept handling. Thank you for pressuring them to get their act together.

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.

You know, I'd love to think that the problem is cyber security is hard -- which it IS -- but I'm starting to get the feeling that the actual problem is that Apple doesn't care about this kind of stuff. So many incredible vulnerabilities going back generations of iPhones and iOS...the zero click iMessages one floored me.

> the zero click iMessages one floored me.

In case there is any confusion, there has been at least one of those a year for the past 3 years.

What is dumb about it to me is that the solution in my mind is simple: don’t give Messages.app private API access. They get access other messaging apps from the App Store can’t have and that’s what’s causing these vulnerabilities, but all they need is APNS and access to the SMS service (which is private but shouldn’t be dangerous… right?).

This last one was an issue in an image decoding.. it was public API.

It’s extremely common for an attacker to find a way to exploit a maliciously crafted image. Take a look at libpng, https://www.cvedetails.com/vulnerability-list/vendor_id-7294...

The problem is not that cyber-security is hard, but that a trillion dollar company is incapable to handle security disclosures.

In which case—if it’s a legitimate deficiency—that doesn’t bode well at all for any other commercial enterprise. This arms race is always tilted in favor of the attacker.

There are much smaller companies which handle security disclosures much better.

but there are many many many more that don't, which impeaches the few that don't. The fact that I can reach the CEO of my local small business on the phone is a great when they're sympathetic to my plight. it's actually to the company's detriment when it turns out they're a raging asshole.

I remember some of early Android phones that ran manufacturer maintained Kernel turning out immune to then-undisclosed RCEs years before disclosure.

I think it’s less about disclosure handling but more about being motivated to pay for or build a black magic code analysis tools.

got any links? that sounds like a fascinating story to read!

Cybersecurity is a genuinely hard problem, but stuff like this is dropping the ball entirely. It's not hard to solve exploits like faulty permission-checking after they've been reported to you.

Sure, there are always going to be problems you miss. I can forgive them shipping with zero-days, it happens. Failing to respond to reports is just that: failing.

It really helps add some color to the motivations behind notorization. It seems ridiculous to me that I have to jump through so many hoops to run an executable that I trust. Especially when Apple can’t be bothered to follow up on real vulnerabilities that have already been reported.

Exactly - any PR propaganda about notorization or signing making it safer for users is just BS. It's a gate-keeping mechanism that adds a layer of power to apple and prevent any control of the app market from slipping away.

Along with a solid bit of resume building for SecEng, I'd say yeah exactly that.

Worse is the fact that the bulk of Apple’s security on Mac is codesigning/notarisation, and a primitive signature-based built-in antivirus. Windows seems to be doing so much better that it’s not even close, and in ways that aren’t user-hostile.

Not to mention that there are still no mandatory security courses in CS curriculum at most major universities.

Or better, we could stop making excuses for trillion-dollar companies with terrible security practices.

i agree that we need to hold massive corporations to a higher standard, but security is incredibly difficult. this comment is more directed at all of the comments who are dismissive of how difficult good security is.

even some of the sharpest security/privacy minds on the planet, who work for organizations who exist purely to make secure software or hardware stumble often.

now add in that we actually expect our devices to also be usable, and yes, security is very very _very_ difficult.

if someone hasn’t learned by now that every device will eventually be cracked, we should question their ability to reason.

now again, we should absolutely expect more from apple/google/$company than we do, but we also can’t hand-wave away that security is very hard.

I mean, Google does a far better job than Apple responding to reported vulnerabilities, pays a team to find vulnerabilies, has extensive fuzzing infrastructure, etc. Even among its peers Apple stands out as particularly bad.

Apple makes ridiculous amount of money, and many Apple fanboys I know believe their devices are hack-proof.

I don’t think of my devices as being hack-proof, but as being the best set of trade-offs for me personally between security, privacy, usability, etc.

Agreed. I use Windows/Android for the same reason- I know what I'm giving up but the upsides are important enough to me. I am talking about people who don't have much clues about either.

i’m not sure anyone who is at least semi-informed believes their devices to be hackproof.

it’s more likely they’ve considered which security issues they’re personally concerned about and decided the other choices are as bad or worse.

once we actually dig into the specifics of an issue–especially one as complicated as personal threat models combined with actual usability–it’s rarely a “my device is now unhackable” cartoon caricature.

> The problem is that cybersecurity is ridiculous hard problem.

This is why I wonder why "minimize your data exposure" is such a controversial opinion.

Because it makes developing new features slightly slower and that is for mostly stupid reasons deemed unacceptable.

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 lines of code in Safari, but we don’t push updates when ready since we don’t want to cause update fatigue, so you’ll need to wait 4 weeks for the fix to come in the next programmed OS update”, and so much more. Even Android seems decent security-wise, since many of the processes that would cause security concerns get updated through Play Store, even in really old phones.

Another example: my grandma doesn’t have WiFi, and I bought her an iPhone, but iOS updates can’t be done on 4G, which can only be bypassed by internet-tethering a computer (which she doesn’t have), downloading the full IPSW, and installing it. She was on iOS 14.0 until 2 weeks ago when I fixed it. And with Safari being, according to security researchers, much less secure than Chrome, that makes me shudder. This isn’t an “anecdote” or an edge case, not everyone lives in a developed country and millions are just like my grandma, and Apple’s poor security design leaves her vulnerable for zero good technical reason, where Android wouldn’t. (They just dropped Google Play Services support for Jelly Bean a few months ago, so even an old Android phone would be reasonably secure). Caring about security requires thinking of details like this.

The other day I tried to update my Macbook over a personal hotspot and it happily downloaded about 2GB before the computer went to sleep and I was greeted with a "Whoopsie, failed to download the update, try again" message when I woke it and, of course, it would just start over again. They don't even support resuming the download! That's just embarrassing.

Strangely I did the same thing last night and it did resume, although you only see the resumption when it starts. There's no prior indication that it will resume.

it depends on your free storage. if it is less than X % they will try to download it one go. the resumable download will download all in chunks and than concat them.

Just tried it again. I have 70GB available. Got on the hotspot, started the download, unplugged the laptop, waited for it to go to sleep, woke it up - same result. I had to accept the EULAs again and it started to download from about 50mb.

Having attempted (unsuccessfully) to write a resumable HTTP/HTTPS downloader, which is what I suspect nsurlsessiond is using behind the scenes - it's really hard to get it right. Meanwhile I expect to be able to start a BitTorrent download, throw the laptop down the stairs, take out the hard drive and be able to successfully resume it on a different computer because that's a protocol that was actually designed for it.

But Apple has the luxury of controlling both the server and the client. Why isn’t it just a matter of using HTTP range requests?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requ...

And if they need to get more clever than that, why not have a BitTorrent-like map of chunk hashes. So you download the update, check the hash of the whole thing and if it fails the hash check, download the chunk hashes which will be say a 256 bit hash for every individual 32 MB chunk of the file. And for any chunk that fails the hash check, use a HTTP range request to download it again.

We can only speculate, but my guess is some combination of “didn’t feel the need to” and “the code responsible for this is nested 6 layers deep between 3 different frameworks”.

I’ve now tried three times to update Safari. The first two times I left the laptop on charge with the lid open (I have it set to auto update). The third time I did it manually and watched. It got the download ok, but failed during install. It told me the update failed, but with no reason or suggestion regarding what to do next.

Edit: I should point out that not everyone has a high data cell account. For example, I’m retired, and we don’t spend much time on the road. When we do, we’re careful how we use data, and we depend on wifi at restaurants and hotels.

We are pretty heavy Internet users at home (Starlink), but the cell plan is 2GB per month, shared between me and my wife. We rarely overrun that.

I think that there are a lot of retired people with small phone plans and no WiFi. All they do is a few phone calls and a bit of email with the family. So, updating those phones frequently is problematic. They probably take them to the phone store where they bought them.

Microsoft has been all over the cyber security news due to their repeat vulnerabilities in Exchange and Azure AND the way they have handled disclosures made to them

u must have missed reading this : ".. Microsoft or Google: both seem responsive and eager to fix within 90 days (mostly) .."

but then u not need to read it. and who would given all the exquisite experiences with M$ and/or Goo compared to nightmares Apple delivers to u, overpriced, ofc

in a sense it is good reading tho after all in that it indicates that exactly those are not the one's one does meet in Apple-communities

It's spelt "you"

> but iOS updates can’t be done on 4G

> This isn’t an “anecdote” or an edge case, not everyone lives in a developed country and millions are just like my grandma

In too many countries, mobile data is incredibly expensive. If Apple were to allow over-the-air OS updates, you can bet it would take only a week until the first class-action lawsuit by people having their data caps blown through because they did not understand that updates are huge.

In many other countries, 4G is so inexpensive that many people use it as their primary Internet connection though.

They don't see a need for a modem hooked to a wired line necessitating a second subscription and procedures to follow when you move apartments, when in any case you will have a 4G connection that follows you around on your smartphone.

I've been using 5G as my primary internet connection since January 2020. It's much faster than wired broadband in buildings that don't have fibre installed. It's also cheaper (I pay £30/month for unlimited data), there's no contract locking you in to 12 or 24 months of service, and I can take it with me whenever I travel or if I move house.

If you have a desktop, how do you provide the 5G connection?

Is there a better way than providing a wifi hotspot with your mobile phone?

I have a Huawei E6878-870 5G mobile WiFi (other brands are available), which provides a "proper" WiFi base station, so no need for a phone hotspot. I have a separate cheap SIM card for my phone.

I get that, but given that some countries have insanely restrictive Wi-Fi data caps (I heard 200GB, which I would probably blow through in a week or less), I don't see the problem. Even if updates-over-4G are disabled by default, power users should be able to turn it on. My grandma has 70GB for 15€ a month; she only makes FaceTime calls, so uses on average 4GB of data a month. I'd love to use SharePlay to share her screen, and teach her how to use her phone, but that won't be possible, because she can't install the update; it'll have to wait until the next time I travel to see her.

I hear that Android lets you enable updates-over-4G, but allows carriers to block the feature. That's detestable! Surely, if I pay for data, I should be able to use it for anything (legal) I deem important? I don't like corporations making those decisions for me.

> My grandma has 70GB for 15€ a month

I'm German, and ... wtf, I'm envious. We have three carriers: O2 (which is cheap, but their network is horrible), Vodafone (which is expensive, has a good network, and is constantly plagued by issues with its customer service) and Telekom (expensive, good network and decent customer service).

Telekom's cheapest plan is 40€ a month which has 6GB, and the biggest plan before flat-rate (at 85€) is 24 GB for 60€ a month...

To be fair, looking around a bit, you can get

14 GB for 13€ (https://www.handyvertrag.de - it's a brand of Drillish, reseller of the O2/Telefónica/E-Plus network)

40 GB for 19€ (https://bestellung.vitrado.de/offer/index/2b5pv1)

Yeah, all of that is O2. The problem is, their service is straight shit outside and barely tolerable inside of urban areas at best. My s/o is on their network, it's ridiculous.

Given they can apply censorship per region I'm sure they could apply a simple setting change per region if they wanted to.

Google makes you explicitly confirm that you want to download using cellular each time you update, noting that it might induce charges. There, fixed, how come geniuses at apple haven’t considered this? Given how nowadays there’s a toggle for 5G and someone on hn told me it’s due to contract with carriers, I reckon the answer is that sweet sweet money.

Apple's entire bug reporting system has always been massively dysfunctional. It is little surprise this extends to their handling of externally reported security issues as well.

> my grandma doesn’t have WiFi

Tech workers have difficulty taking into consideration lifestyles they don't know exist, which is understandable. At the end of the day this comes as another consequence of the lack of diversity in tech, I guess.

So, is this the lack of grandmas working at Apple in software development? This is nothing you can fix by following some diversity ideology. This is a question of respecting different requirements from different user groups. You cannot mirror every user group in the development teams. How do you represent people of old age, with illnesses, or certain disabilities in a development team? How do you represent people living at certain locations in the world in a development team? How do you represent poor people or people of low education? Or how do you represent people which live under oppressive regimes or are the continued victims of criminals?

All these groups have different needs and expectations to the products they buy or lease. And development teams and their business cannot expect to understand that by having a more diverse development team. They have to do better requirements engineering, they have to listen better to their customers and they have to decide and prioritize those needs and expectations. E.g. A/B testing has abysmal consequences for the needs and expectations of minorities.

Now that you mention it, I think there's a real lack of grandmas in tech... maybe I shouldn't be saying this publicly, but we don't have any at our company.

One of our product managers is a grandmother (she is actually taking an early retirement soon because her 4th grandchild is on the way).

We are in the B2B/B2EDU space so the "As a grandmother, I think..." line of thought does not apply. However, she has frequently had insights and observations that none of us would have come up with. Once implemented, they have been very successful/profitable.

So yes, absolutely, unless your company wants to be in a very specific niche, the lack of true diversity in your company is a drag on your success.

PS - my grandfather had a tech job in Sunnyvale. He passed away last year at the age of 92. Point is - everyone alive has lived in a world with pervasive technology and computing. "They're old and can't understand this stuff" is pure BS.

> One of our product managers is a grandmother

> However, she has frequently had insights and observations that none of us would have come up with

> So yes, absolutely, unless your company wants to be in a very specific niche, the lack of true diversity in your company is a drag on your success.

The conclusion you are drawing here, does not follow from your two observations above. The fact that your product manager has had insights, that nobody else had in team, does not mean a "lack of true diversity in your company is a drag on your success." Some diversity may help in certain situations and in others not. The above mentioned insights and observations might just be the result of competence and more experience of the product manager or incompetence of the rest of the team. There may be many other reasons. We don't know. We have one observation and should refrain from generalizing. That this is because of more diversity is just a speculation. A speculation that fits an often repeated narrative, but that doesn't make it a logical conclusion.

Sometimes you need to accept you just aren’t the target audience of a product.

You may love cars. You might think Tesla’s are amazing. But if you live on a small island without an electrical grid, it might not be the car for you just because it doesn’t come with its own solar panels.

But what do you do when you realize you are neither the target sheep, ehh, customer, of iOS nor Android? But that is just the other side of the coin of what I wrote about the development teams. Sometimes, they just have to accept that diversity is not going to solve all problems.

Owning an iPhone with no other means of Internet connection makes one not the target market for an iPhone?

All these different groups your speaking of are called personas. Apple should have each of their personas identified based off their technical prowess, their life experiences, health, how they connect for user updates and whatever else may differentiate a group of users from one another and needs to be considered and accounted for.

Once you have that you create a user journey map for each of those personas - in this case they need a user journey map for updating. Your test teams then have to take each persona and run through testing with those constraints and capabilities in mind.

They don't have a high-speed network or are using a cellular network? One or more personas should have accounted for that. Color blind? One or more personas should have accounted for that and there's software available that can make your screen as it appears to those who are colorblind.

These personas should be corporate-wide - these are your customers after all. I would be shocked if Apple isn't doing something like this, but then again, after getting a glimpse at how the sausage is made I've come to the conclusion Big Tech isn't any better at creating and testing software (well, not that much better) than anyone else.

Of course, these groups are called personas in software engineering circles. I was answering to people who believe diversity will somehow fix all problems of this world. And they do not talk about personas. They talk about minorities, victims and races.

Before Apple or any other customer company describes personas, there is an explicit or implicit decision of which personas to consider and which not. But most consumer targeted companies hide which personas they consider and which not.

> They talk about minorities, victims and races.

When I mentioned diversity, what I actually had in mind was that all tech workers in California have wifi, and probably find this so normal to connect your phone to wifi that they expect any normal user will do this on a daily basis.

I'm not a grandma but I'm a tech worker with a very different life style. Like the person I was replying to's grandma, I have no wifi. Like her, I have to fake it from time to time so that my Android phone will backup photos, accept to download Google drive documents, etc.

So the diversity I had in mind is rather a diversity in location and lifestyle.

That's what I understood you to mean too. I just added in differently-abled people. I've never seen a persona based off minorities, "victims" (not sure what that means in this context?), or races. It's always been capabilities and life experiences.

I don't think this is diversity specific. I know plenty of young people who just use LTE and tether their computer to their phone.

I think its more a legacy thing, when iPhones first came out this made somewhat sense, to spare the mobile networks the load.

If you have a 5G iPhone you can set it to download updates over 5G but its just plain stupid you can't do it over 4G. Over 2G or 3G it makes a little bit sense.

> 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 compiler itself needing to be updated as part of this process?

Or are you suggesting they would ship the diff for the binary? For one, I don't think the delta in the resulting binary would be as small as the delta in the source, due to addresses changing, etc. There are tools like bsdiff which can 'intelligently' handle this, but I believe they aren't widely used for operating system updates, as opposed to standard userspace binaries.

In addition to this, the diff shipped would be relative to whatever version the device is currently using, which would necessitate storing a very large number of diffs, especially for binaries, or else computing it on the fly (which simply shifts the burden from disk space to CPU cycles).

Or have I misunderstood you entirely?

They're suggesting a patch in the classical sense of the term. A whole hog OS update does not qualify. These complications were addressed 20+ years ago when whole hog OS updates were unreasonable. It requires a certain amount of cleverness, but that may be too much to ask of the fruit company.

https://en.wikipedia.org/wiki/Patch_(computing)

I understand the change would be a patch, but that's separate from the question of how you encode and ship it, surely? How are you suggesting a small patch would be shipped?

Android does them just fine: https://source.android.com/devices/tech/ota/reduce_size

In particular, bsdiff has been around for a very long time and is an industry standard binary diffing tool.

Yeah, I mentioned bsdiff in my original comment. I don't think Android uses it for operating system updates, though, as far as I can tell. I believe that page is describing APK updates (i.e. app updates).

Well, monthly OS updates for Android tend to be just a few megabytes, so I'm presuming they use some sort of binary diffing algorithm.

In the simplest way, not unlike Windows Update: snapshot filesystem, start filesystem transaction, unzip changed binary files, check new files integrity, end transaction.

Indeed, Apple used to distribute patches this way in the past.

You also could ship a list of updated system files hashes, compare to the installed files and just download the changed ones, like rsync.

Better than shipping a whole new disk image every small update they do.

Yeah, I'm sure it's theoretically doable, but it's one of those things which would almost certainly require substantial work given the massively complex edifice of iOS. (And the iOS IPSW format, or even iOS DMGs/ADIs, are very different from the OS X patches you mentioned.)

It's cheaper to make things that aren't maintainable. We optimize for the dev, not the platform or the user.

It's the same lazy dev culture that gives us Electron apps, or the lazy sysadmin culture that gives us docker.

It's cheaper to create massive incomprehensible and unmaintainable edifice that requires massive storage / processor / network inefficiency to maintain versus well thought-out and "clever" systems that work efficiently.

Personally, I wish the days of optimizing for low-resource machines, slow network connections, and expensive storage weren't gone. As an end-user I think the results of moving away from a culture of optimization haven't been good. I think the ship has sailed, though.

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.

> I haven’t heard anything like this about Microsoft or Google: both seem responsive and eager to fix within 90 days (mostly)

Print Nightmare was part of a risky call in the printing subsystem design which was recognized as such when they made it in the 90s. That specific vulnerability was disclosed to Microsoft in 2020, accidentally disclosed in public in June, flailed at with incomplete patches and bad documentation all summer while ransomware gangs exploited it, and has theoretically finally been patched in the September release following multiple incomplete patches.

The Exchange auto discover bug announced yesterday had previously been reported with Microsoft telling the reporter that it wasn’t a bug. Oops.

This is hard but it’s also important to remember that this is an industry-wide failure because it’s been cheaper to clean afterwards than invest in proactive cleanup of old “stable” code, and it will likely continue as long as there are no financial consequences for a breach. Adding consequences would change that dynamic but would also be a massive change to the industry. It could endanger open source and would almost certainly make everything more expensive.

It would not certainly make everything more expensive. The cost of breaches is significant, though difficult to quantify, so the cost of effective prevention could be lower.

That's _possible_ but fundamentally I'm looking at this from the perspective of requiring new work to be done by expensive people (infosec, dev, ops are all in-demand skills) — maybe some of that comes from changing team priorities, in which case the cost is less feature work, but in most cases I'd expect that to be hiring. There aren't many breaches which have direct costs greater than that because companies have been able to avoid penalties or compensation in most cases. If the cost of a breach was greater than, say, a year of free credit monitoring that calculation could change dramatically.

Ransomware has already changed this somewhat: now the cost is halting operations for a potentially lengthy period of time, and that has spurred a lot more awareness that the current model is insufficient but not from what I've seen significant efforts to change it.

I hate blaming people and pointing fingers. It seems to me, that the current CEO, who was the CFO at the same company before, would be well advised to drop the "numbers & metrics" MBA mindset.

Written five years ago but sadly still relevant: https://steveblank.com/2016/10/24/why-tim-cook-is-steve-ball...

Agreed here.

Depending on her data plan, downloading several tens of gigs over her 4G could have resulted in a rather exciting phone bill.

> “you need a 3GB OS update even if the only fix is 3 lines of code in Safari,...”,

If Apple really cared, it would have changed this scenario by now. A 7year old android device which can download/sideload latest Firefox is technically more secure for web browsing than an latest iOS device which is yet to receive an OS update with the critical patch for the Safari.

But as Tim Cook proudly claims, People who use Apple products are those 'don't want to take risky decisions themselves' maybe they'd be willing to wait for that OS update however long it takes.

Existing frameworks?

Does anyone knows the technology stack Apple uses?

Have they considered asking security questions on interviews instead of algos?

like you know, shitty performing algo can be always rewritten, leak or 0day cannot be reverted

The problem is that cybersecurity is ridiculous hard problem.

Security is challenging, but there are lots of things we know how to do better that many software developers still aren't doing. For example, if you're still writing application-level software in an inherently dangerous programming language in 2021 and that application handles important data in a connected device, you're part of the problem. If you ship a networked hardware product with a standard password for all devices or forget to disable the backdoor access used during development, if you use encryption or hashing methods that are known to be weak, etc. These things obviously won't solve all security problems, but they are low-hanging fruit that is still being left on the tree far too often.

> The problem is that cybersecurity is ridiculous hard problem.

This is hard for me to believe for a company the size of Apple. They were recently the wealthiest company on the planet and are worth over a trillion dollars IIRC. They could slow down their software development process, focus less on adding new features, and prioritize fewer security holes. It seems like such a huge risk to them that their devices are basically always vulnerable. But the general public never really hear about these 0-days so they may have some ability to ignore the problem.

The cynic in me imagines that someone at Apple knows about these bugs and they are shared with spooks for exploitation. One could imagine that even for a responsible disclosure program, they could share details of every new vulnerability with some three letter agency who could have months of use out of them before a patch is finally released.

> recently the wealthiest company on the planet … They could slow down their software development process, focus less on adding new features, and prioritize fewer security holes.

My inner cynic¹ has a slightly different take on that: You don't get to be the wealthiest company on the planet by doing the right thing at the expense of the profitable things.

¹ He says, pretending it isn't also his outer and all-consuming cynic!

Ah, then the cynical part of you will recognize that selling a widget is more lucrative then avoiding the loss of someone else's private data.

Or at least that's what I just realized.

people are unwilling to wait or pay more for high quality products when a low quality substitute that is just barely adequate is available

If companies respected and paid platform/architecture engineers, or SecOps/SysAdmin types fair amounts of money and treated them with respect, instead of just throwing more and more money at hordes of mindless devs who are "pushing product", as virtually every single company does, maybe this problem wouldn't exist.

I've had this conversation too many times. Security isn't hard, it's just that nobody has respect for it. The guy who understands software security isn't getting the respect he deserves. The situation is so bad, some companies are literally hiring people who know the equivalent of script kiddie "penetration-testing".

Pay security engineers enough and listen very carefully to what they have to say. Literally the only companies who seem to understand this basic concept seem to be the intelligence agencies, and a few other high profile companies.

> The problem is that cybersecurity is ridiculous hard problem.

I don't believe that. Making perfectly secure software at large scale is indeed very hard, but a lot of security issues we see every day have little to do with lack of perfection. There's a ton of low hanging fruit out there.

> The junior to senior developers are just using existing frameworks with poor documentation.

Yes, I do believe that the modern way of quickly ducktaping junk together while paying little attention to security does make for lots of security issues, which might give someone the impression that cybersecurity is ridiculously hard.

Security requires proactive effort. It's not ridiculously hard, but it needs to be done, it requires time (just as anything). Leaving it for "hope you don't write buggy code" and "does colleague notice the gaping hole in code review" is not doing security, it's just winging it.

And I've never really been asked to do security, even when literally working on a security product. Everyone just seems to assume security is an automatic byproduct of skilled programming, but it's not when the pressing concern is "how many hours/days/.. does it take to ship this new feature oh and we have three dozen other features that need to be implemented soon" and "can we get it sooner?" and "why is it taking so long, it's not that hard!"

It needs to be discussed, planned, designed, reviewed, tested, verified, questioned, audited. Just like anything else, if you want quality. None of this is ridiculously hard, but it needs to be done for it to be done. If it's not being done, it's that the organization doesn't care about it.

In a lot of ways it's similar to technical debt. Are you taking the time to avoid it, reduce it, get rid of it? No? Then you're accumulating it. Security issues accumulate just like technical debt when ignored. And even the most skilled programmers do generate technical debt (because they don't jump into a problem with perfect knowledge of what needs to be done). Depending on the organization, they may or may not get to fix it. Many organizations just don't care and would rather have the devs work on something "more productive."

You talk as if the Apple engineers couldn't have fixed those 3 vulnerabilities in half a year because it's too difficult for them...

> It's the same never-ending war as anti-cheat vs cheat.

Building secure software and building anti-cheat are nothing alike.

Anti-cheat is fundamentally impossible (on a true general purpose computer) because you’re building software that has to run in an environment where it can be dissected and modified.

Building a secure device (something which has to satisfy certain security properties for all inputs through a constrained API) is fundamentally possible. We’re just too lazy and cheap to do it. I don’t even think it’s “ridiculously hard” - we would just have to spend more money on correct by construction designs, formal methods, etc instead of spending money on flashy UIs and random features no one cares about.

The number of employees at Apple working on security is vanishingly small compared to the number of employees, say, working on random siri features. And the way they approach security in many apps is also wrong. Instead of having people with formal correctness backgrounds designing the APIs against which apps are built, they just have developers with no security background putting everything together and then have a few security people trying to pick up the pieces.

It would really help a lot if:

(1) We used safe languages like Go, Rust, C#, Java, and Swift instead of 1970s YOLO languages like C and C++.

(2) Our operating systems were designed from the ground up to be secure in a modern environment.

Unix (all flavors) and Windows were both built long before security was anywhere near as much of a concern as it is today. Their security posture is very lax by modern standards. Applications have a ton of permissions by default including seeing the whole network and filesystem. Everything runs with only basic memory isolation. Everything has access to an enormous system call surface area.

It is extremely hard to apply security in retrospect to an insecure system, especially a complex one with lots of legacy support requirements. You are going to be playing a whole lot of "whack a mole."

A modern secure OS would begin with the principle of least privilege and be built from the ground up to isolate applications as much as possible from anything they are not entitled to access.

Oddly enough the web browser might be the best attempt. When you browse the web you are basically swimming in malware, and you are relatively safe.

Entitlements are great, right up until someone has to start manually deciding what access to give. After being blocked or questioned by the OS a handful of times, people are going to either disable the security or effectively disable it with wildcard matches.

Don't apple make the frameworks they use? Im pretty sure they could just patch them when they are notified of a vulnerability.

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.

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.

I've updated the article to include a timeline for each vulnerability

Thanks!

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?

Isn't it better to persist medical data on the device rather than putting it on Apple's servers?

What's funny about it is that apparently some of their WatchOS/device combos have FIPS 140-2 and FIPS 140-3 certifications. Pretty useless security theatre if you then shuffle the data around to other operating systems or into arbitrary servers with complex infrastructures.

Not if your API design is so bad that any third party can access them, apparently.

Aside from that, I'm pretty sure they'll also get stored on their servers, if you have not declined all the nagging iCloud sync requests.

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 encrypted form [1]. Garmin devices also collect heart rate, sleep stats etc. and I have never thought of these as medical (health-related yes, but not medical). The line is thin though.

Since you work in the industry, perhaps you could share your opinion how such data should be treated?

[1] https://www.apple.com/healthcare/health-records/

> menstrual cycle length, biological sex and age, whether user is logging sexual activity, cervical mucus quality, etc.

These are hardly data collected by Apple Watch, unless someone is being inventive with one. These come from HealthKit. Which is alarming as HealthKit can also sync your EHR from health providers.

Diagnostic data is a category of medical data. So yes, that stuff is considering medical data.

According to the GDPR health data is a special category that needs extra care and heart rate falls in that category:

"Information derived from the testing or examination of a body part or bodily substance"

"cervical mucus quality" sounds like it fits that definition.

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

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

I am not able to compile the first two of these (after the first two I stopped trying) with the newest Xcode on iOS 15.0. I haven't tried the other two or older tools.

The source code as given also had syntax errors in it.

Just curious, what kind of compilation error are you getting?

'init(machServiceName:options:)' is unavailable in iOS

This is just a check built into Xcode to try to keep you from accessing XPC in iOS. The code on GitHub bypasses this by calling this method dynamically through Objective-C runtime

This makes one question whether there really are any security vulnerabilities at all. Perhaps Apple isn’t fixing these because there’s nothing to fix? I don’t know enough to say whether these vulnerabilities are real or not.

The Gamed 0-day compiles just fine. I can run it on my iPhone with iOS 14.8 and it shows 300 contact information gathered apparently from various sources without me giving any permission at all.

Which XCode version are you using to compile?

12.5.1

I am on 13.0, perhaps they fixed it because I can't compile on older iOS versions with XCode 13.0 .

PS I was wrong, it works. See the comments above.

maybe they 'fixed' it by not allowing any app of this kind (specific Api call) in the appstore? wouldn't challenge you to try and publish an example app though...

This is trivial to bypass

Follow the links to GitHub, the code there compiles perfectly, the PoC inside the article is just a shortened version

Thank you for the explanation! Will give it a shot.

P.S. Yes it works! Perhaps add a comments in the short version where it says

//This shortened version does not compile, use the GitHub version of the code

It said "proof-of-concept" and I generally expect PoC to work as presented. My bad for not reading everything carefully.

Good idea, I've added the comment

>com.apple.gamed

I like the poetic nature of exploiting that one.

I really wonder how different the mobile security landscape would look if researchers were treated seriously. This is a mistake that Google, Apple and even Microsoft (for the short time they made phones) all made, and now we have to live with the consequences of that. Along with your "post privacy" world, we may as well march this as the epoch of "post security". It just depends on how much someone is willing to spend to engineer one (or three) zero-days from your target's machine. This used to be feasible, but recent ransomware and surveillance malware has proven that it's commoditized now.

>This is a mistake that Google, Apple and even Microsoft (for the short time they made phones) all made, and now we have to live with the consequences of that.

What consequences are we living with?

Fear of data leaks for one. That’s never going to be zero, but it could be a lot better than it is.

I never thought that hacking like in Star Trek will be anytime truth. But it looks like we slowy head for it...

At some point Apple has to realize their bounty program as its currently being run is tarnishing their privacy branding.

Can Apple retroactively identify apps that might have exploited these vulnerabilities to exfiltrate personal data? In my understanding they receive the full source code of an app for review, so they probably have an archive with all revisions that they could go through using automated tools to identify exploit code? Would be good to know if these exploits have been used in the wild, being able to exfiltrate the entire address book without any user involvement whatsoever is quite scary.

It would probably take the exploitation of a security hole in Apple's systems to find out, as they clearly have no desire nor incentive to do this.

Is it odd that I'm now hoping this might happen while also hoping for them to start patching up security holes?

Edit: typo

> In my understanding they receive the full source code of an app for review

I did not know that, is that even legal that Apple gets to look at your IP.

Apple doesn't get your app's source code when reviewing it, they just receive the binary.

There is no way they could prove that an app HASN'T exploited this. They don't get source code, only compiled binaries, and with objective-c's extremely dynamic nature, any app could technically receive a HTTP response containing strings containing class and method names to dynamically look up and invoke, maybe even based on the app's IP address or only on specific dates. So calls to these exploitable APIs could have happened and there would be no way to prove otherwise.

Furthermore, no one stops you from developing an app and planting RCE vulnerability inside the binary. Then you can exploit it remotely when necessary and execute the code that exploits any iOS vulnerabilities known to you.

True but it is complicated by the fact that code signing is generally enforced for executable segments. (JIT compilation entitlements are generally not available to apps beyond Apple's own MobileSafari builds)

Thanks to @illusionofchaos for sticking to responsible disclosure and putting themselves under legal risk for the benefit of Apple's users.

Who knows if any of these are exploited in the wild already (Pegasus, etc) and by whom.

I really hate the path Apple is taking. They make excellent products, really the average Joe simply loves Apple products. But they need to stop acting anti-consumer and anti-developer to “protect” their IP. At this point they could release the schematics of iPhone 13 and still people will buy Apple’s iPhone than someone who copied them. Rant over.

Actually, these vulnerabilities are good evidence that Apple does not make excellent products.

Probably means they make "good looking" products. But underneath the hood, it's spaghetti.

Apple is going downhill. It's amazing how a trillion dollar company can't even get this right. Wouldn't be surprised if the IS&T group is running the bounty program. Probably offshored to hell at this point.

Obscure ad-tech companies would love to get those installed apps like they were aggressively doing (Facebook & Twitter too) about 5 years ago.

Facebook and Twitter exploited 0-day security vulnerabilities to collect private data?

Can show the proof link please?

I believe the poster was referring to the practice of testing if an app was installed by calling [UIApplication canOpenURL:] —- as I recall Twitter was found to check for hundreds of different apps, to feed into their ads and analytics business, and Apple later changed it to only be callable 50 times.

Nit: for 50 different schemes, not 50 times.

And you have to provide those schemes in your App's plist as well if I recall correctly. Gated pretty hard.

> medical information (heart rate, count of detected atrial fibrillation and irregular heart rythm events)

> menstrual cycle length, biological sex and age, whether user is logging sexual activity, cervical mucus quality, etc.

Wat? How, and under what circumstances is it collecting stuff like cervical mucus quality??

Edit: ah, maybe I misread - it's "whether the user is logging cervical mucus quality" I think. Still, wtf?

You need to select female under health.

I don't have an iDevice. Is this a built in health app or an API for apps to record stuff?

The Health app stores all this data and third party apps can ask to record to this database.

I get happy about iOS security vulnerabilities, because they allow users to mess with the software of the device they own through jailbreaking.

Hopefully one of these will end up in a jailbreak.

At least the Game Center one is something an app developer could easily stumble upon. I don’t want to know how many apps are already exploiting this.

That's exactly how it happened for me. I noticed that when an app logs into Game Center, the notification is shown inside the app, and not in a remote process like when you choose contacts of compose an email. That led to easily discovering everything else.

Security through obscurity is a very bad idea. This is the main Achilles heel of Apple.

Obscurity and secrecy seem to be so ingrained in the Apple culture that I don't see this changing anytime soon short of some kind of existential crisis or a major threat to a substantial amount of their revenue. And even then it isn't likely to be easy to turn the tide.

Right now we see these negative externalities of security vulnerabilities being "paid for" by their customers, in the vast majority of cases seemingly unwittingly, but that can only go on for so long before it backfires (even if it's a long time).

I suspect when Apple doesn't want to pay the bug bounty, they just ignore it.

After the disclosure of the last critical 0-day, I went to update the OS is my four iDevices. I upgraded three of them to iOS 14.8 with no trouble, but when I went to update the fourth it wouldn't let me update to 14.8 but rather only offered me the option of upgrading to 15.0. I didn't want to upgrade to 15.0, so I called Apple support and the first-line tech said, "Oh, I can definitely help you with that." I thought to myself that I'd give long odds against, but let's wait and see. Long story short, the matter has now been escalated two levels and is still not resolved. Funny side-story: at one point the first-tier tech suggested I try upgrading the phone using iTunes. iTunes has not existed in MacOS for quite a while now. The way you talk to iDevices now is through the Finder (which actually makes a lot more sense), but apparently their tech support didn't get the memo.

Apple used to be the company that made devices that were secure and "just worked". Now they are as bad as Microsoft in the bad old days, and no one makes computers that "just work" any more.

:-(

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

> This is a complete myth.

No, it isn't. Snow Leopard was awesome. Mavericks was also pretty solid. In fact, I'm still running that on my machines today.

Yes, it is. Snow Leopard and Mavericks are not devices. The quote I am responding to is:

> Apple used to be the company that made devices that were secure and "just worked".

Unless your first generation iPod still works wonders.

Mechanical hard drives that lived in pockets and backpacks inevitably died. People seem to have been happy with the lifespan they got, though.

Ok, old (first gen) Mac Pro, preferably running Snow Leopard.

BTW, I've one still running. Also a G3 from 1999 still up.

Sorry, I'm old-school. A computer is a device.

> A computer is a device.

Correct. A computer is a device. Snow Leopard and Mavericks--your two examples-- are, however, not computers.

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.

None? I had an iPod Touch that lived in my glovebox for 9 years and it never died. My Rio Karma on the other hand basically disintegrated. Thanks for asking!

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.

They might've sliced it into two parts on macOS, but it's still iTunes, with all the issues iTunes had.

Sadly, Apple always gives the "latest and greatest" version all the security updates, and is more selective about backports, see here: https://support.apple.com/en-gb/HT212814 for stuff you're unprotected from if you stay on iOS 14.

This includes arbitrary code execution with kernel privileges.

This has been the case for a long time for Apple, which forced me to break my Catalina boycott (remember the macOS Vista stories here?) because I don't want unfixed, publicized 0days on my machine.

Here, I'll save you the trouble: download the iOS 14.8 IPSW for your device, and then in the Finder when your device is connected hold down the option key and hit "Update". Then select the IPSW and it'll update your device with that.

You can download the IPSW from ipsw.me (you actually grab the file straight from Apple and it's digitally signed, so the malware risk is zero) and perform the update yourself by option-clicking the Update button in the iPhone window in Finder.

Thanks!

I'm wondering how the health-data incident works with respect to the GDPR.

Apple says it stores Health data in a protected way on the device.

In reality, health data is leaked through logs and can be accessed by any other app. It is impossible to tell whether or not this data has been accessed in the wild.

Since Apple failed to implement their claimed security features properly and you need to assume exploitation by apps in the wild in the worst case, this would require a disclosure to GDPR authorities. Did they do it? Were they fined yet?

According to my understanding of GDPR, the data would need to contain personal information i.e. something that allows you to link it to an identifiable person. Quick search on google gives the following definition of personal data [1]:

"Personal data are any information which are related to an identified or identifiable natural person."

So if there is no personal data in the logs, it should not be a GDPR breach.

[1] https://gdpr-info.eu/issues/personal-data/

Not sure how far fetched an accusation can be in this case.

If the data is accessible in plain text on a device that is clearly linked to an identifiable natural person, which is data that an attacker can easily access, the point of "just this one log file not containing the data" is pretty much mute.

Would be an interesting case.

It really is interesting. Apple could potentially claim that they didn't connect Personally Identifiable Information with the leaked health data, but a third party app, which gathered that data, did.

Depends on what exactly was in the logs. Did it contain my emergency contact from Apple Health? Or my own contact data? That would be bad.

You can see the logs in JSON inside Settings app. Also if two vulnerabilities are used together, you can get full name and email and connect it to health data

Are there any partial mitigations you can take until these are patched?

Don’t update your apps till after Apple releases a patch. The first two are API calls that apps can make.

An exploit wishing to exploit these vulnerabilities has to be coded to make these calls. Most apps don’t dynamically construct arbitrary API calls. In fact, you can’t do that in Swift AFAIK. You have to drop to Objective-C or C to do that.

So most apps need to be updated to exploit the vulnerability. The only exceptions would be apps that are intentionally constructed to call arbitrary APIs or at least with arbitrary parameters. The first would be a violation of developer agreements but that hasn’t stopped people in the past. Also, these aren’t even private APIs. These are public APIs that got exploited due to not properly checking parameters/entitlements.

I wonder if Apple isn’t running static analysis tools right now to look for these vulnerabilities against all apps.

It’s pretty trivial to encode a backdoor into your app that would let you remotely call native code of your choice.

I guess this is the reason Apple restricts apps from executing downloaded code.

This is without downloading additional code. Reuse attacks such as ROP, or you could just embed an interpreter with the ability to alter native register state. It’s not hard to get Turing completeness into your app in a way that lets it call whatever it wants.

Yeah, it wouldn't be too hard to write an interpreter. It is a lot like compiler class.

> I wonder if Apple isn’t running static analysis tools right now to look for these vulnerabilities against all apps.

On a side note, this is one more reason Apple can cite for their App Store exclusivity. If there is a vulnerability in the OS exploitable by apps, and they can’t get a patch out in time, they can screen and prevent the download of such dangerous apps.

Not a popular position here I know. But I’m correct no?

No. Those static analysis tools don't catch everything. There are relatively well known and somewhat widespread tricks to avoid being caught by them.

I speculate that GameKit is basically abandonware by Apple. They even got rid of the app a few years ago.

There probably hasn't been hardening of it in years and the initial work was probably developed in haste.

This is systemic. Apple has a bad habit of abandoning software that isn't a priority. So, one shouldn't be surprised that Apple hasn't fixed these exploits. And I wonder if the author has fully mined GameKit for exploits yet. Perhaps there are more to be found.

The architecture of iOS and OSX isn't conducive to security AFAIK. It is more of an add-on as one can see instead of being architected in.

I haven't checked further, maybe authentication token can be used to gain access to Apple account and more data. Also one other method could used to write arbitrary data outside of an app sandbox, that might be useful for further exploitation.

Catching some is better than catching none. Apple will be evolving their analysis tools too as they go along.

> But I’m correct no?

You're not correct - Apple can still scan apps installed from elsewhere. With a user opt-in, Android can verify side-loaded apps - no App-store exclusivity required.

The whole point of Swift is to be next generation Objective-C and C on Apple platforms, no need to drop down to other languages.

In fact, the prof of concepts shown in the article are all written in Swift.

I wasn't clear. It is dynamically constructing an API call that Objective-C allows. The objc_msgSend stuff.

Which you can call directly from Swift.

You are right.

https://steipete.com/posts/calling-super-at-runtime/

Look at the code of gamed exploit that I've uploaded to GitHub, the app is written in Swift and it calls Objective-C runtime functions from it

Delete any apps you don't want others know you downloaded or be linked to you immediately. If your wifi name for some reason is something sensitive rename it. The address book/sms one is tricky, maybe make a backup of your iPhone and if you're truly paranoid delete all your contacts and sms messages and restore them when Apple releases a patch?

This is truly a massive fail on the part of Apple and I hope there is as big of a backlash from their users.

Apple might have left these vulnerabilities for Pegasus like softwares including the sotfware used by FBI and other agencies.

I don't know why you're being downvoted. My mind immediately went to this, given the relative obviousness of the exploits (compared to the massive supercomputer fuzzing runs done by Project Zero &c), and given their refusal to either document or fix these serious vulnerabilities in several releases.

Has anyone on HN been able to run any of these 0-days to see if they work on their device?

Yep, here is a thread which has screenshots on the latest iOS update: https://twitter.com/keleftheriou/status/1441252412061204486

One more reason why "closed systems" are not magically superior. Closed systems still have vulnerability, and the culture that creates and maintains the closed system shuns those that find flaws in it. So much so that security researcher becomes, in their minds and practices, synonymous with black hat actors. Why would you report vulns to a company that doesn't want it? Go sell it elsewhere and use that money to get a better device. Yet researchers persist, for the good of secure technology.

Unfortunately, the fact of the matter is that the only way for Apple to recognize a problem is to have a lot of news and influential tech media cover it.

> ... one was fixed in 14.7, but Apple decided to cover it up and not list it on the security content page. When I confronted them, they apologized, assured me it happened due to a processing issue and promised to list it on the security content page of the next update. There were three releases since then and they broke their promise each time.

I think this is 100% intentional.

Bug Bounty programs represent everything Silicon Valley hates: Interaction with customers and relationship management. They are _forced_ to actually communicate and respond to people and can't get away with just treating them like cattle.

That contact and messages access exploit is quite neat. Some might say it even looks straightforward. I can only assume this is the "private API" that darkly patterned apps use, because it looks that obvious.

If Apple will not do the ethical thing then why should people try to help them? I say give Apple 30 days and then sell it to someone else. Let Apple live their own reality.

Just looking at the readme sample code it appears to be using APIs unavailable in iOS, so where is the vulnerability?

It's just marked as unavailable. Apple does that to try keeping people from using XPC on iOS. Use the full code from GitHub, it has a bypass for that Xcode check

Unless they have evidence of it getting past Apple and into the App Store, just doing it dynamically doesn’t change anything

If you have a developer account that you are willing to sacrifice and don't mind the possibility of legal action, you can try that. I've managed to upload the binary built from the source code from gamed exploit repository on GitHub to App Store Connect and installed it onto my own device via TestFlight. I didn't submit it for review, but if the functionality would have been concealed, it would easily pass.

As far as I know, how the review happens is that reviewers just install apps onto their iPads, tap through all the screens they can find and make their decisions based purely on that. So if an app connects to server and asks what it should do, it's possible to make an app behave differently for reviewers and all other users.

Imagine an iMessage 0-day 0-click worm that disabled every iPhone for a month…

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.

All the hard working security researchers are this much appreciated by the rotten Apple.

I am seriously considering throwing my $800 phone at a concrete wall.

The story continues: https://news.ycombinator.com/item?id=28672680 https://habr.com/ru/post/580272/ (TL,DR: Apple says 'thank you' and did nothing once again)

Until we understand and push through a system (whether law or practice) that makes harming others, especially against their will and intentionally, far more costly than the massive returns and profits they today produce, NONE of these kinds of behaviors will ever cease.

The examples are numerous;

* Violation of human right to privacy and property

* Violation of human right to not being tracked

* Illegitimate wars

* Pollution

* Drugs (legal and illegal

* Government incompetence

* Siphoning off potential and sabotaging developing countries through human resource poaching called "immigration"

* The fed fraud

* Government theft and fractional enslavement through taxation

* More fraud through inflation

* Yet more fraud trough money "printing"

* And for emphasis; being "secure in their persons, houses, papers, and effects, against unreasonable searches and seizures" (and no, that does not only apply to the government)

...and probably many more that I am forgetting are all immensely profitable activities that damage and destroy and defraud large numbers of people while providing immense profits and benefits to a very small set of people who are also the most powerful.

You may disagree with what I have to say, but fundamentally regardless of which set of things you do and don't support all have an underlying mechanic that they defraud everyone while immensely profiting a parasitic ruling class, and that applies to both the things you think are good (e.g., immigration) or bad (e.g., wars). The parasitic ruling class has us squabbling over meaningless crumbs while they are bursting from picking our pockets and exploiting us as they always have, even if their con and lies have changed over time.

You’re getting into implied relative privation here. Yes, bad things exist, and yes, they aren’t controlled in a way we’d like. That doesn’t excuse Apple and isn’t that relevant to an argument about Apple’s immediate responsibility for its errors.

I’m convinced that the modern role of US political parties is to simply keep the masses squabbling. I wish we could get rid of gerrymandering and the two party dominance.

Unfortunately, the Supreme Court decided 5-4 that the courts should have no power here, so its up to state legislatures. (https://www.npr.org/2019/06/27/731847977/supreme-court-rules...)

Totally agree here. It has to be intentional at this point.

Yes. Hyperpartisanship is the way to maintain minority control of an ostensibly majority-controlled system. Both parties feign gridlock over popular policy but cooperate on what their owners want. Populist support for policies doesn't matter when people are kept divided along party lines. "Radical" nonconformists who aim to do what voters want can always be defeated from within their party if not by the other side.

> Siphoning off potential and sabotaging developing countries through human resource poaching called "immigration"

You think immigration should be illegal?

> Government theft and fractional enslavement through taxation

You really had me in agreement with the first few items. You are not a serious person.

I'm going to guess that they're referring to only allowing "cream of the crop" immigration. (eg H1B or other visas often are only open to top candidates, not everyone)

The problem with the argument that this is crippling developing countries is that it's often the case that the top talent can't really shine in their country. They can't realize their potential, either due to the lack of means or corruption or envy or whatever. I am from a third world country and a large part of our scientists did great things because they immigrated, at the same time, there are many great minds here that to do anything at all have to partake in an endless uphill battle.

Like, I'd totally love to have our top engineers and scientists come from the West and do some amazing things here (they 100% can make a great change), but I feel that they actually just can't.

Also it ignores, as i've observed with Filipinos in Canada, that they often send like half of their paycheck back "home" . Some of them live in developed world "squalor" (like many people to a house, or taking the bus) so their families can live like royalty in a low CoL area.

I get your point and have considered it myself. It is a big problem, but it is also a function of the rather rapaciousness of the US economic/immigration system and model itself. NOTHING would stop the US government to fund the opportunities in whatever country in question, but also, there is no reason why "immigration" could not be a kind of skill building/sharing and development plan where you are given the opportunity to go to the USA for a set number of years and/or cycles, and then you know you are going to transition back to your home country where you will then use those skills/knowledge to help and build your country.

It is actually extremely inefficient the way the rapacious American system in particular works (but also Canada and increasingly the overall EU). There is far more utility to be gained from making exponential strides and advances by the "human resources" as they are even referred to, by uplifting and developing their home country than to serve the US ruling class in ever more desperate search for "growth".

And then of course there is also the fact that immigration is short sighted and a pure measure of the incompetence and failure of government. If you are importing people, you have failed to adequately govern to meet your needs and it also will make you reliant on that immigration while you will ignore even building up any kind of domestic capacity.

Then there is of course the consequence of immigration dependence coupled with international development and growth too when the source of "immigrants" dries up because people will want to life in their home countries where they can be among their own and development has narrowed the difference between comfort levels in the USA. We will be seeing this effect increasingly in the near future as, e.g., Indians see no reason anymore to move to the USA because the US university is not even as good as a local university, let alone American society is crumbling and cracking at all seams. It will be compounding effect. I already see it happening.

Says the person who has no idea that he is not in one bit a serious person. Immigration the way you have been trained to think of it like a mindless dog that does tricks for snacks is a con job of the ruling class to defraud its citizens to increase their profits. And that doesn't even address the fact that "immigration" that you are clearly conditioned to have a co-dependent positive response to, is utterly destructive for the origin society and economy like something out of a scifi movie where an alien ship is just stripping out all the resources from the planet; immigration sucks the life force and potential from a society and destroys the culture so that billionaires can compete to see who is the first to become a trillionaire. And they have you on the hook.

And yes, how is it not factional slavery when the freed person in the USA in 1865 kept 100% of what he earned all his life and paid no property or sales taxes when he bought something … but you pay about 60% of all your earnings over the course of your life to the government that has you enslaved to support others against your will with resources it takes from you. You are a slave to the new aristocracy that is the bureaucratic state that you must pay your serf dues to (which are higher than all serfs ever paid) so that the Lord can use your earnings to bequeath to the aristocratic class their income and assure their loyalty.

If you are not a slave, are you free to leave the USA and life somewhere else? No. Your US government owner will come after you wherever you life to make you pay taxes on your income. Are you free to just quit your job or are you shackled with the bondages of debt slavery? I think we both know the answer to that, regardless of whether you want to acknowledge it.

So try to not be such a mindless herd animal and think for yourself a bit.

We detached this subthread from https://news.ycombinator.com/item?id=28640879.

As bad as this is for people who use iOS, I think it's good in the long run.

People here are getting boggled down in details about how is it possible for this to happen and what sort of policies apple has internally for it to be possible, but that doesn't really matter. Any company even 10% the size of APple should not be given the benefit of the doubt because obviously they'd all prefer not to have the major/minor embarrassment, if they can. Bounty programs exist not because they care about security of their customers only, but it's also a way to promote the company as security-conscious and avoid having 0days sold on the black market.

But to overcome this you can just continue publishing 0-days straight to the public. Put really easy to use sourcecode on github/bucket/srht/etc... allowing script-kiddies and copy-pasters to make use of them easily. This will either drive people to lose trust or force Apple to scramble to release fixes, either way it will push them to respect researchers and fix their bounty program or setup better security guidelines in general.

Props to the author for following through and releasing.

Does this rise to the level of a class action lawsuit? Especially if I theoretically started receiving spam texts with more personal info (my name, contacts’ names) in them starting about seven hours ago?

I haven’t, I’m just curious.

Why must iOS use WiFi to run critical security updates? I assume it’s a kickback from telecoms to reduce network bandwidth from users with unlimited mobile data plans?

Does iOS have any way of telling if you’re on an unlimited data plan? If not, maybe it’s just to prevent the footgun (and subsequent bad PR) of somebody accidentally updating the OS over an expensive metered connection. But it could also be a carrier demand, not really sure.

Settings > Cellular

It shows my carrier, amount of data used and shows remaining on my plan.

Mine reads,

    Usage: Used 7.43GB - Unlimited

If I click on it it has 3 fields.

Data, Calls, Messages

Data reads the same here. Calls and Messages simply say ‘Unlimited’

My phone does not have this (iPhone on 15.0 in the US, AT&T).

Huh, I’m on the US too, T-Mobile.

Mine doesn't have this either (Europe), and I have unlimited data too. I have a "Data Plan" setting under "Mobile Data", which is not activated, so I'm guessing that setting is only there if your provider gives you a data plan that Apple recognises.

This has changed on the newer phones (12, 13):

https://www.macrumors.com/2020/10/21/iphone-12-can-download-...

You got downvoted but this is correct. For a long time iOS didn't allow you to perform big downloads (apps, updates, etc) from the device if you were on mobile data because they didn't want to upset the carriers. But I believe those days are over.

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.

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

If Apple allowed a jailbreaking application make it to the App Store, then I do not trust their processes to not fail again.

> static analysis which Apple obviously uses as part of its approval process

This analysis is a joke, it just scans strings inside binaries against the list of symbols corresponding to what Apple considers to be Private API. Gamed exploit can be uploaded to the App Store and binary will pass their analysis with flying colors

> My actions are in accordance with responsible disclosure guidelines (Google Project Zero discloses vulnerabilities in 90 days after reporting them to vendor, ZDI - in 120). I have waited much longer, up to half a year in one case.

"Responsible" disclosure guidelines only benefit corporations. They do not protect consumers. Why should independent researchers - working for free, no less (and sorry, the well-below-minimum-wage pittance that is most bounties does not count as not working for free) have to cow tail to corporate guidelines?

If you find a vulnerability, do everyone a favor and disclose it immediately. This places pressure on the corporation to fix it immediately, instead of ignoring it indefinitely.

FYI, it's "kowtow", not "cow tail".

Also, it's "This makes it immediately available to exploit before a fix can even _theoretically_ be developed", not "This places pressure on the corporation to fix it immediately".

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.

There is no $100K coming.

Apple hopes you'll stay silent by dangling a hypothetical $100K (or whatever large amount) in the vague future. Once they've fixed the bug, they no longer have an incentive to pay you so they won't.

Haven't they done this in the past? "Oh thank you!" then "Actually we already knew about it and had a fix planned, so no bounty for you"?

Yes.

In some cases when they did pay, they paid significantly less than their published rates.

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 :)

I think the behavior is very Russian.

Hacker: You have a vulnerability bounty program. Well here are three. Pay up.

Apple: [silence]

Hacker: [interprets this correctly as a fuck you.] Fuck me? Fuck you!

Me: Love it!

Seems more likely it'll just take 3-4 years with months of silence at a time, based on the extremely few security Radars I've ever filed as a developer. 90 days to publication is certainly a valid choice, but it's also a personal choice that reduces a probable $100k payment in X years to a certain $0 payment today. I would be fine with that delay. OP is not, and that's fine too. I don't know whether that's an acceptable choice or not to anyone else, but Apple should be disclosing their communication practices a lot more clearly here. I discourage participation by anyone who isn't willing to wait a year between replies.

You’re claiming that they maliciously lie and refuse to payout because, based on OP, they screwed up on release notes and didn’t get it solved within the 90 day crunch period between WWDC and release.

It took so little evidence for you to decide it’s hopeless and declare as fact your prediction. Maybe you felt this way before this post? Otherwise I’m just not sure how to respond.

Given that (according to the author) they've already lied at least twice ("processing error, will be in next release")...

... what gives you such high hopes that he will ever get his 100K?

Don’t count someone else’s money.

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.

I agree, but the shame of getting 0-day exploits published on the web by someone who doesn't work at Apple might shame them enough to change.

Sue Apple and lose another 100k.

If Apple can't handle properly disclosed vulnerabilities on their main revenue generating platform what does this say about other companies? Nothing good I'm afraid.

Meanwhile the contact list on my dumbphone is perfectly safe. Time and again that's been proven to be the right decision, convenience seems to trump security in the eyes of many but I just don't want to give this up until there is a 'cloud free' smartphone.

Would you consider something like the PinePhone once it’s a bit more usable?

I realize you don't mean it that way, but this comes off as a bit 'whatabout-ish'.

It doesn't say absolutely anything abut other companies. It just says that Apple doesn't take security nearly as seriously as their Marketing and Sales department would want us to believe.

Dumb phone might just be backdoored as well, how do you trust it? Do you have an open source dumb phone?

> If Apple can't handle properly disclosed vulnerabilities on their main revenue generating platform what does this say about other companies?

It doesn't say anything about other companies, it just says that Apple doesn't give two shits about relationships with security researchers, despite their massive resources and wealth even when smaller or FOSS teams do much better. Apple are the king of user experience which made them insanely wealthy but that's about it. In every other respect they are anti-consumer, anti-developer, anti-reparability, anti-researcher, anti-openness, anti-standardization AF and act like major a-holes in general to anyone outside their org who isn't a customer.

It's not that Apple can't be better on the other fronts if they actually wanted to, it's that they actively choose not to be, as that has no impact on their stock price or consumer experience and in consequence to their executive pay. So why do things differently if people still buy your products?

At this point, I wouldn't be surprised if the "Apple is more secure and has less vulnerabilities" moniker just stems form researchers getting tired of dealing with Apple's BS of not acknowledging or paying them, so instead they just keep quiet and sell the 0-days they find on the exploit markets (hard working honest researchers still need to eat and pay rent) only for those exploits to later end up in the hands of shady companies like NSO or nation states, therefore leading to no news in the mainstream media about Apple related vulnerabilities. Win-win for Apple I guess.

I wonder if the culture of leaking and dissent within Apple is enabling information to leak which assists the 0day authors?

did you mean 0day exploit authors? otherwise, wouldn't the actual authors of the 0day be Apple employees on the iOS team?

They don't need leaks to find vulnerabilities... although the source code would probably help.

Maybe it's just me, but these aren't what I think of when I hear 0-day.

These are serious, but I was guessing remote code execution or sandbox escape. It seems like we're talking about bypassing privacy controls though.

That said, Apple needs to take this much more seriously. They created the program reluctantly and it shows.

FYI, 0-day just means "first time made public".

Completely aware of that. Just a weird perception thing for me.

It means a vulnerability is made public while there is no patch available. As opposed to releasing the information a number of days after the patch was released.

It doesn't even really mean that anymore. From the blog post here:

> I've reported four 0-day vulnerabilities this year

They're just using 0-day to mean "a new vulnerability finding disclosed to the vendor privately", which is becoming the new definition of the term.

From an earlier post: This is a boat load of mission critical data.

- all contacts, including 3rd party messaging apps, with metadata (interactions, timestamps, other stats) - full address book - whether any app is installed - SSID of connected wifi

- medical info - device usage - screen time - device accessories

I must have missed the medical info.

I guess I don't consider contacts mission-critical though I definitely would not want them exposed and generally don't give apps access to them.

There needs to be a distinction between 0-days that make remote code execution possible and those that don't. This is still a pretty damning data leak.

There is a system, cvss scoring https://www.first.org/cvss/specification-document

0-day ... what they mean is .... I found an issue. Its hardly a 0-day, they've not posted any evidence of it actually being used in the wild, just that "it can be used". Why is a normal "ooh look a bug or two" all of a sudden hair on fire world is burning news.... oh yeh ... I get more attention this way by exaggerating

Apple may have a terrible bug bounty and response process ... but call a spade a spade

... I saw a bird this morning ... help theres dinosaurs on the loose!!!!

What is your definition of 0-day? Because they are exactly right, this is a 0-day. Whether it's already actively being exploited or not has no bearing on the definition.

I'll refer you to https://en.wikipedia.org/wiki/Zero-day_(computing) to make up your own mind.

normally I'd define it as something found in the wild being exploited already ... not a bug thats been found, reported and "ignored"

this seems to be a zero day just because Apple haven't seen fit to respond the the reporter

> normally I'd define it as something found in the wild being exploited already

Yeah, but ... that's not what it means. You can choose to define "spoon" as "fork" too, but I don't see how it's useful to go around complaining about other people using the actual definition of the word.

A zero day is a zero day, regardless of whether it's been exploited in the wild. There's a decent chance that well-funded bad actors have already found these, and you have no idea whether they've been used or not.

Reply on news.ycombinator.com