Live data from Hacker News

Disclosure of three 0-day iOS vulnerabilities

habr.com

371–380 of 464 posts

Re: Disclosure of three 0-day iOS vulnerabilities

#371

Earlier quoted context omitted.

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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#372
post #209

Earlier quoted context omitted.

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#373
post #369

Earlier quoted context omitted.

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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#374

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.

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…

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

Re: Disclosure of three 0-day iOS vulnerabilities

#375

Earlier quoted context omitted.

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…

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

Re: Disclosure of three 0-day iOS vulnerabilities

#376

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

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

Re: Disclosure of three 0-day iOS vulnerabilities

#377

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…

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#378
post #229

Earlier quoted context omitted.

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

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

Re: Disclosure of three 0-day iOS vulnerabilities

#379

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.

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.

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

Re: Disclosure of three 0-day iOS vulnerabilities

#380
post #369

Earlier quoted context omitted.

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).
Post reply on HN