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

81–90 of 464 posts

Re: Disclosure of three 0-day iOS vulnerabilities

#81

Post by wyattpeak »

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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#82

Post by pvg »

hsbauauvhabzb wrote: post #71
pvg wrote: post #43

Earlier quoted context omitted.

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

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#83

Post by saagarjha »

babesh wrote: post #46
jonahx wrote: post #42

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

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

Re: Disclosure of three 0-day iOS vulnerabilities

#84

Post by mdoms »

hsbauauvhabzb wrote: post #8
58x14 wrote: post #7

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…

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?

Gargantuan.

Re: Disclosure of three 0-day iOS vulnerabilities

#85

Post by eloisius »

wyattpeak wrote: post #81
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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#86

Post by howinteresting »

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.

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

Re: Disclosure of three 0-day iOS vulnerabilities

#87

Post by Mtinie »

emsy wrote: post #77
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.

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.

Re: Disclosure of three 0-day iOS vulnerabilities

#88

Post by akiselev »

pvg wrote: post #43
58x14 wrote: post #26

Earlier quoted context omitted.

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

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

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

Re: Disclosure of three 0-day iOS vulnerabilities

#89

Post by yccs27 »

saagarjha wrote: post #83
babesh wrote: post #46

Earlier quoted context omitted.

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

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