551–560 of 886 posts
Earlier quoted context omitted.
It may be the case that either the kernel vulnerability hasn't been analyzed or fixed yet, or that they were not able to capture it. Many of these exploits have multiple stages and grabbing the later ones is difficult.
Is that still true when you control the source code and compiler? Or just for external researchers?
[flagged]
> The shellcode would then disable memory protections like ASLR and DEP that normally prevent arbitrary code execution. This would allow the attacker to execute a ROP gadget chain or other payload to jailbreak the sandbox and run remote commands on the device. This sounds like chicken - egg scenario. Can you clarify how original shellcode bypasses those protections? I don’t think you can disable DEP on runtime.
That being said, Apple implements a ton of mitigations, both on a hardware level and on a software level which generally makes exploits on Apple devices interesting to analyze and see how they bypassed stuff.
Edit: For clarity, Apple requires both codesigning and implements PAC, among others. mmap'ing or ROP won't make the cut in this case.
Earlier quoted context omitted.
This is a false comparison. Being hacked by NSO isn’t an accident. There’s an agent involved here with clear intent to harm and significant monetary motives. If in a car accident we knew one party intentionally caused the crash (and were paid for it handsomely), we’d hold them responsible, regardless what claims car companies make regarding safety.
That doesn’t matter. If your air bag fails to deploy after a crash, the manufacture is responsible for the product defect. It doesn’t matter if the crash was an accident or someone intentionally and specifically crashing into you, the manufacturer is responsible for a defective air bag. The manufacturer is not responsible for the crash, only the defective product. The other driver is not less responsible for a death…
Should they have done something about this? I believe so, but they are not marketing themselves as secure against state actors. They have release lockdown mode, which may or may not have prevented this particular exploit.
It's important to keep the demographic of iPhone users in mind. The average user do not want to be inconvenienced for security measures irrelevant to them. And if a competitor (Android) is providing a better experience, then Apple, from a business point of view, have no choice but to make the most secure system they can, while still providing the same UX.
All that said, I do believe that they should implement zero trust on first contact, as a default, with the option to enable explicit trust for every attachment. I just do not believe that this will be any major impact on these actors capabilities.
Earlier quoted context omitted.
What code auditing? Are you claiming NSO has access to iMessage and iOS source code? NSO seems to be finding more and more bugs by poking a black-box alone, while Apple cannot seem to be able to fix by looking at the source code with all the fuzzing and verification tools, and much more $$$ at their disposal.
Sorry I thought it was obvious that I meant reverse engineering the closed source pieces of iMessage and auditing the open source bits. Source code just speeds up the process for vulnerability researchers, so Apple has a leg up in this regard. "Are you claiming NSO has access to iMessage and iOS source code?" The last NSO zero-click was in an open-source library reachable from iMessage. This vulnerability is likely n…
Ehh…it’s complicated. Often this is not the case.
Earlier quoted context omitted.
Given all the major tech companies aggressively fuzz everything maybe, just maybe, you're missing the additional possibility: fuzzing is still random and extensive fuzzing does not mean you will encounter the same code paths as anyone else. You need to understand "do fuzzing" is not a magic trick to find all bugs in software. Similarly: definitionally you will only ever see the bugs that are not found prior to shippi…
Fuzzing is not a magic trick, in the same way as invariants are not, and unit tests are not, and debugging is not. All these techniques have degrees of mastery, and if applied carefully, and in combination, can save you a lot of grief. Dumb fuzzing will not get you anywhere, same as dumb unit testing, and dumb debugging. In this case, iMessage is particularly well suited for some smart fuzzing because all the attack…
I'm confused why they waited to patch this vulnerability until it was found in the wild. Or am I misunderstanding? Is this not the same NSO zero click exploit from like a year ago?
[flagged]
How did the "Citizen Lab" connect this to the "NSO Group?" Is it just pure breathless speculation?
Earlier quoted context omitted.
That sound so naive, or fanboy - it ain't funny. GPS can be spoofed, and the entire hardware that decodes it replaced. Trying to hide a hardware device that's sold in billions is not going to happen.
You are severely underestimating the power of an entity like Apple. HN regularly spouts opinions that if US companies don't like the GDPR they should just stop doing business with the EU. That's a massive block of consumers and I highly doubt any company that likes its bottom line is going to take that approach. But we're talking about one company here that simply should stop selling their crap to the highest bidder.…
So 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?
this is a problem of all nation states wanting this kind of service, not of israel in particular.