Live data from Hacker News

Disclosure of three 0-day iOS vulnerabilities

habr.com

281–290 of 464 posts

Re: Disclosure of three 0-day iOS vulnerabilities

#281
post #264

Earlier quoted context omitted.

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

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?

Re: Disclosure of three 0-day iOS vulnerabilities

#282
post #274

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

Re: Disclosure of three 0-day iOS vulnerabilities

#283
post #27

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?

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#284

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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#286
post #209

Earlier quoted context omitted.

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

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

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

Re: Disclosure of three 0-day iOS vulnerabilities

#288
post #249

Earlier quoted context omitted.

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 devic…

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#289

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

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#290

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.

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

Post reply on HN