Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disclosure of three 0-day iOS vulnerabilities

habr.com

Post reply on HN
Print view View original

291–300 of 464 posts

Re: Disclosure of three 0-day iOS vulnerabilities

#291

Post by mschuster91 »

FabHK wrote: post #277
mschuster91 wrote: post #242

Earlier quoted context omitted.

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#292

Post by howinteresting »

samhw wrote: post #281
willis936 wrote: post #270

Earlier quoted context omitted.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#293

Post by WA »

larsnystrom wrote: post #284
raspasov wrote: post #241

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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#294

Post by api »

JoeOfTexas wrote: post #69

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

Re: Disclosure of three 0-day iOS vulnerabilities

#295

Post by WA »

cybrox wrote: post #280
evercast wrote: post #227

Earlier quoted context omitted.

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#296

Post by 1vuio0pswjnm7 »

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#297

Post by Nextgrid »

tonypace wrote: post #254
howaboutnope wrote: post #54

Earlier quoted context omitted.

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

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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#298

Post by skylanh »

dspillett wrote: post #235
TaylorAlexander wrote: post #182

Earlier quoted context omitted.

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

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#299

Post by Nextgrid »

tonypace wrote: post #255
mmarq wrote: post #236

Earlier quoted context omitted.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#300

Post by jtbayly »

user-the-name wrote: post #256
blub wrote: post #158

Earlier quoted context omitted.

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

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