Here we go again... NSO Group has a long history of 0-click, 0-days against iMessage, and just a few months ago Kaspersky caught a different zero day iMessage exploit targeting their staff. If Apple repeatedly fails at securing their devices from an attack vector that has been demonstrated over, and over, and over... no wonder China is banning government officials from using their devices.
China not worried about 0-clicks on Apple. They are worried about US-Apple collusion with iOS software.
NSO group iPhone zero-click, zero-day exploit captured in the wild
111–120 of 886 posts
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#112So at what point does the world bring sanctions against Israel for allowing organizations like this to exist there? Everyone knows NSO is just a dubiously legal version of common APT groups, so how do they still exist after these years?
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#113Earlier quoted context omitted.
[flagged]
The US government gives them billions of dollars and they help the US government maintain puppet dictatorships like Saudi Arabia..
For all the things Israel has done against the US's wishes (like West Bank settlement), the US has struggled to do just one thing Israel doesn't like: the Iran nuclear deal. But at least one of our major parties is somewhat willing to push it. I think they're also somewhat annoyed with our focus on Ukraine.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#114Earlier quoted context omitted.
Please... Androids no better. At least Apple will have it patched within the year of discovery. Can't say the same for other Android vendors.
Interesting how your response makes it seem like the person you're responding to mentioned android at all.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#115Earlier quoted context omitted.
Android is moving away from C and towards more secure languages. From one of their recent blog posts, the majority of code written for android is now in memory safe languages.
Apple also has memory-safer languages it is moving to: Swift: A memory-safer systems programming language: https://www.swift.org Firebloom: A memory-safer C variant: https://support.apple.com/en-il/guide/security/sec30d8d9ec1/... Not sure what the answer is for existing memory-unsafe code.
It's an engineering approach that involves writing "A buffer overflow issue was addressed with improved memory handling" an awful lot. Hopefully one day they will finish improving the memory handling!
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#116Earlier quoted context omitted.
Some of the problems with iMessage have to do with the fact that it's integrated with the system SMS app. It seems that there are a large number of legacy requirements in the GSM spec that require the Messages app to be privileged in some way, especially with regards to automatic processing of data received. There have been plenty of iMessage or Messages related vulnerabilities. I do wish there was a way to turn off…
Apple have a service which attempts to do this, BlastDoor. The issue here is feature surface area unrelated to GSM. My guess from the CVEs is that this exploit revolves around sending a valid Wallet/PassKit item attachment which has a malicious image. The payload is safely _deserialized_ by BlastDoor itself, but is then passed off to the PassKit framework which happily detonates it. IMO Apple should make a middle gro…
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#117Earlier quoted context omitted.
I don't think the EU is that much concerned about E-waste. If they were, they would not waste their time with chargers and instead focus on appliances and cars.
These things are not mutually exclusive, iirc they are doing appliances & cars, it's just that phones are often highlighted & batteries are usually the first thing that fails and can be easily replaced in all cases die to how build electronics. Charger standardization was in the pipeline for about a decade so not exactly a priority it being only passed now.
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#118Was just wondering why my Mac wanted to update (since it felt I updated it very recently).
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#119Earlier quoted context omitted.
Android is moving away from C and towards more secure languages. From one of their recent blog posts, the majority of code written for android is now in memory safe languages.
Is the programming language likely the issue here?
Re: NSO group iPhone zero-click, zero-day exploit captured in the wild
#120Earlier quoted context omitted.
Please... Androids no better. At least Apple will have it patched within the year of discovery. Can't say the same for other Android vendors.
Android is moving away from C and towards more secure languages. From one of their recent blog posts, the majority of code written for android is now in memory safe languages.
In Rust we can't trivially write a bounds miss by mistake. But in WUFFS we just can't write a bounds miss at all. Like, that's not a thing in WUFFS, it doesn't compile. You can write your own bounds checks and show WUFFS that works, or you can write code which clearly can't have a bounds miss with no checks, that works too. But you can't just "forget" or "screw up" those won't compile.
This would be frustrating in a general purpose language. WUFFS doesn't have a "Hello, World" program because it lacks both strings and the idea of outputing to the screen. But WUFFS isn't a general purpose language, however it's the correct way to write the code that takes image files we got from some dubious source and processes them.
When Apple announced they wanted to provide proper security for vulnerable iPhone users, this is what that would look like coming from a company which actually cared about security. What you got is what it looks like from a company which prioritised marketing.