4 ms·

Can we assume that Apple will continue to fail to secure the iPhone against these spyware companies?

by neilv 1y ago

Gigachad 1y ago
Memory integrity enforcement added to the iPhone 17 range is probably going to be huge for preventing future exploits. At risk people should probably also enable lockdown mode.
- bigyabai 1y ago
  Blastdoor was also supposed to be "huge" for preventing future exploits. Worked great up until NSO Group developed FORCEDENTRY.
  - commandersaki 1y ago
    MIE eliminates a whole class of bugs (memory corruption) and has demonstrated that it stops full chains but also renders them unusable if parts get swapped out. See: https://security.apple.com/blog/memory-integrity-enforcement/ https://security.apple.com/blog/memory-integrity-enforcement... And some interesting excerpts: Both approaches revealed the same conclusion: Memory Integrity Enforcement vastly reduces the exploitation strategies available to attackers. Though memory corruption bugs are usually interchangeable, MIE cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs. Even with substantial effort, we could not rebuild any of these chains to work around MIE. The few memory corruption effects that remained are unreliable and don’t give attackers sufficient momentum to successfully exploit these bugs. Notably, attackers confront Memory Integrity Enforcement early in the exploitation process. Although some issues are able to survive MIE — for example, intra-allocation buffer overflows — such issues are extremely rare, and even fewer will lend themselves to a full end-to-end exploit. Inevitably, attackers must face MIE at a stage where their capabilities are still very limited, leaving few viable avenues for exploitation. This leads to fragile chains where breaking just one step is often enough to invalidate the entire exploit strategy. When that happens, most of the chain’s components can’t be reused, and the attackers have to restart exploit development with entirely new bugs.
    - bigyabai 1y ago
      [dead]
  - Gigachad 1y ago
    MIE is preventing an entire exploit category permanently. Blastdoor is just being more careful in a specific area of the code. It's also not just a case of is it possible to exploit or not, but how much does it cost to develop an exploit, and how long do they last for. If it costs you millions of dollars for an exploit that gets patched a week after it's deployed, you can't use that for mass surveillance. If it costs you hundreds of millions, you can hardly use it for targeted attacks either. The cost of exploiting phones is constantly going up. It used to be within the ability of a single hobbyist developing a jailbreak. Now it's only in reach of the most well funded hacking groups for highly targeted attacks.
Hilift 1y ago
"fail to secure"? Do you really think that with all of the years of iPhone device and account takeovers, from a text message requiring no reading or interaction, Apple with their maximum controlled walled garden aren't facilitating? Apple spent billions moving factories because the US government told them to. They are the keymaker. Apple could do a lot of things, such as preventing the black market for stolen phones from existing. A single city, London, had 80,000 phones stolen in 2024. "...Onwurah argued that "robust technical measures" such as blocking stolen phones taken overseas from accessing cloud services could make devices "far less valuable". "She also pointed to comments by Mobile UK, the trade association of the UK's mobile network operators, who said blocking IMEI in other countries was a "necessary step to dismantle the business model of organised crime". "However, she said when giving evidence, Apple, Google and Samsung had avoided saying why they would not implement the technology." <--** https://www.bbc.com/news/articles/cx2y037pg41o https://www.bbc.com/news/articles/cx2y037pg41o
- gruez 1y ago
  >Apple could do a lot of things, such as preventing the black market for stolen phones from existing. A single city, London, had 80,000 phones stolen in 2024. Doesn't iCloud lock basically already makes a stolen iPhone unusable? What more do you want?
  - hopelite 1y ago
    I’m not sure of the whole dynamic of the stolen phone black market, but if iPhones are still stolen, it seems iCloud lock does not sufficiently deter the practice.
    - gruez 1y ago
      Right, because they're broken down for parts, but there's only so much you can do. For one, every time Apple tries to do something to lock down parts, right to repair people decry it as some sort of trojan horse to shut down third party repairs. Moreover even with parts serialization, there's only so much you can do. There's no inherent way for a bag of electrolytes to identify itself to a phone. The best you can do is add a chip to it and identify using that, but you can't prevent that chip from being transferred.
hulitu 1y ago
> Can we assume that Apple will continue to fail to secure the iPhone against these spyware companies? Fail is an overstatement. Apple is part of PRISM and the functionality is working as intended. When a hole becomes public, it is quickly patched.
- udev4096 1y ago
  This. Apple, along with every "evil big tech", is in bed with NSA which was proven with PRISM
- JumpCrisscross 1y ago
  > Apple is part of PRISM PRISM was semi voluntary. And the legal immunities it operated under expired in 2017.
  - bigyabai 1y ago
    PRISM was also disclosed through a whistleblower, not a FOIA request. I commend your naivete if you seriously think Apple was included in the old wiretaps but exempted from the new ones.
    - JumpCrisscross 1y ago
      > if you seriously think Apple was included in the old wiretaps but exempted from the new ones Irrelevant to the inaccuracy of the statement “Apple is part of PRISM.” Present tense. (Emphasis mine.) It’s important in these discussions to separate the nihilists who are convinced all is always lost from those who know what they’re talking about.
      - bigyabai 1y ago
        It's a pedantic distinction with presumably zero consequences. Which is important to identify as it separates the eternally hopeful from those who've seen this cycle before.
throwaway48476 1y ago
Apple isn't even trying to secure the iPhone. They could have rewritten the imessage parsers in a memory safe language. It would at least take a big byte out of the zero click exploits.
- commandersaki 1y ago
  They've been using Swift for targeted code rewrites; wouldn't be surprised if those parsers will or have been rewritten already.
  - superdisk 1y ago
    Swift is a ridiculously far cry from a memory safe language.
    - commandersaki 1y ago
      I don't know much about Swift, but it has a section in its documentation dedicated to and claiming memory safety: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/memorysafety/ https://docs.swift.org/swift-book/documentation/the-swift-pr... Enlighten us? Edit: Looks like for multithreaded code they suggest you use thread sanitiser, so in multithreaded code it doesn't enforce memory safety. At the same time, I don't see a history of memory safety issues with Swift compared to C and C++, I don't see this being a big deal in practice, particularly if you adopt the strict concurrency checking.
      - superdisk 1y ago
        I use Swift at my job, and all I can say is anecdotally we've had a ton of problems with memory safety. - Swift has a feature where you can unwrap a nullable which is basically just unusable, as it completely crashes the entire program if it fails, with no way for you to gracefully handle it or present a message to the user. And it's a massive footgun, since it has such convenient syntax that makes it seem like it should be used. But no, you have to avoid to like the plague. - There are some Apple APIs where they just disregard their own types, and pass nil to your callback where the type says it's non nullable. This means if you access the var at all, crash. - Concurrent access of dictionary, crash. And very hard to track down why as well since it can be very intermittent; in our case we were using an asynchronous dispatch queue instead of a sync one, so a single keyword. Oops! - Stack overflow, crash. - This isn't really Swift's fault, but in general every single macOS API is riddled with bugs and undocumented behavior. As a matter of fact, I would venture to say that almost every macOS API is virtually undocumented, either since there is literally no documentation or the existing documentation is just names of functions and occasionally an extremely out of date sample app. So IMO it's about as memory safe as C. We're floating around the idea of just porting everything to Rust and moving on, haven't researched or committed to it yet though.

Can we assume that Apple will continue to fail to secure the iPhone against these spyware companies?

by neilv 1y ago

Can we assume that Apple will continue to fail to secure the iPhone against these spyware companies?

Memory integrity enforcement added to the iPhone 17 range is probably going to be huge for preventing future exploits. At risk people should probably also enable lockdown mode.

bigyabai 1y ago
Blastdoor was also supposed to be "huge" for preventing future exploits. Worked great up until NSO Group developed FORCEDENTRY.
- commandersaki 1y ago
  MIE eliminates a whole class of bugs (memory corruption) and has demonstrated that it stops full chains but also renders them unusable if parts get swapped out. See: https://security.apple.com/blog/memory-integrity-enforcement/ https://security.apple.com/blog/memory-integrity-enforcement... And some interesting excerpts: Both approaches revealed the same conclusion: Memory Integrity Enforcement vastly reduces the exploitation strategies available to attackers. Though memory corruption bugs are usually interchangeable, MIE cut off so many exploit steps at a fundamental level that it was not possible to restore the chains by swapping in new bugs. Even with substantial effort, we could not rebuild any of these chains to work around MIE. The few memory corruption effects that remained are unreliable and don’t give attackers sufficient momentum to successfully exploit these bugs. Notably, attackers confront Memory Integrity Enforcement early in the exploitation process. Although some issues are able to survive MIE — for example, intra-allocation buffer overflows — such issues are extremely rare, and even fewer will lend themselves to a full end-to-end exploit. Inevitably, attackers must face MIE at a stage where their capabilities are still very limited, leaving few viable avenues for exploitation. This leads to fragile chains where breaking just one step is often enough to invalidate the entire exploit strategy. When that happens, most of the chain’s components can’t be reused, and the attackers have to restart exploit development with entirely new bugs.
  - bigyabai 1y ago
    [dead]
- Gigachad 1y ago
  MIE is preventing an entire exploit category permanently. Blastdoor is just being more careful in a specific area of the code. It's also not just a case of is it possible to exploit or not, but how much does it cost to develop an exploit, and how long do they last for. If it costs you millions of dollars for an exploit that gets patched a week after it's deployed, you can't use that for mass surveillance. If it costs you hundreds of millions, you can hardly use it for targeted attacks either. The cost of exploiting phones is constantly going up. It used to be within the ability of a single hobbyist developing a jailbreak. Now it's only in reach of the most well funded hacking groups for highly targeted attacks.

Hilift 1y ago

"fail to secure"? Do you really think that with all of the years of iPhone device and account takeovers, from a text message requiring no reading or interaction, Apple with their maximum controlled walled garden aren't facilitating? Apple spent billions moving factories because the US government told them to. They are the keymaker. Apple could do a lot of things, such as preventing the black market for stolen phones from existing. A single city, London, had 80,000 phones stolen in 2024. "...Onwurah argued that "robust technical measures" such as blocking stolen phones taken overseas from accessing cloud services could make devices "far less valuable". "She also pointed to comments by Mobile UK, the trade association of the UK's mobile network operators, who said blocking IMEI in other countries was a "necessary step to dismantle the business model of organised crime". "However, she said when giving evidence, Apple, Google and Samsung had avoided saying why they would not implement the technology." <--** https://www.bbc.com/news/articles/cx2y037pg41o https://www.bbc.com/news/articles/cx2y037pg41o

gruez 1y ago
>Apple could do a lot of things, such as preventing the black market for stolen phones from existing. A single city, London, had 80,000 phones stolen in 2024. Doesn't iCloud lock basically already makes a stolen iPhone unusable? What more do you want?
- hopelite 1y ago
  I’m not sure of the whole dynamic of the stolen phone black market, but if iPhones are still stolen, it seems iCloud lock does not sufficiently deter the practice.
  - gruez 1y ago
    Right, because they're broken down for parts, but there's only so much you can do. For one, every time Apple tries to do something to lock down parts, right to repair people decry it as some sort of trojan horse to shut down third party repairs. Moreover even with parts serialization, there's only so much you can do. There's no inherent way for a bag of electrolytes to identify itself to a phone. The best you can do is add a chip to it and identify using that, but you can't prevent that chip from being transferred.

hulitu 1y ago

> Can we assume that Apple will continue to fail to secure the iPhone against these spyware companies? Fail is an overstatement. Apple is part of PRISM and the functionality is working as intended. When a hole becomes public, it is quickly patched.

udev4096 1y ago
This. Apple, along with every "evil big tech", is in bed with NSA which was proven with PRISM
JumpCrisscross 1y ago
> Apple is part of PRISM PRISM was semi voluntary. And the legal immunities it operated under expired in 2017.
- bigyabai 1y ago
  PRISM was also disclosed through a whistleblower, not a FOIA request. I commend your naivete if you seriously think Apple was included in the old wiretaps but exempted from the new ones.
  - JumpCrisscross 1y ago
    > if you seriously think Apple was included in the old wiretaps but exempted from the new ones Irrelevant to the inaccuracy of the statement “Apple is part of PRISM.” Present tense. (Emphasis mine.) It’s important in these discussions to separate the nihilists who are convinced all is always lost from those who know what they’re talking about.
    - bigyabai 1y ago
      It's a pedantic distinction with presumably zero consequences. Which is important to identify as it separates the eternally hopeful from those who've seen this cycle before.

throwaway48476 1y ago

Apple isn't even trying to secure the iPhone. They could have rewritten the imessage parsers in a memory safe language. It would at least take a big byte out of the zero click exploits.

commandersaki 1y ago
They've been using Swift for targeted code rewrites; wouldn't be surprised if those parsers will or have been rewritten already.
- superdisk 1y ago
  Swift is a ridiculously far cry from a memory safe language.
  - commandersaki 1y ago
    I don't know much about Swift, but it has a section in its documentation dedicated to and claiming memory safety: https://docs.swift.org/swift-book/documentation/the-swift-programming-language/memorysafety/ https://docs.swift.org/swift-book/documentation/the-swift-pr... Enlighten us? Edit: Looks like for multithreaded code they suggest you use thread sanitiser, so in multithreaded code it doesn't enforce memory safety. At the same time, I don't see a history of memory safety issues with Swift compared to C and C++, I don't see this being a big deal in practice, particularly if you adopt the strict concurrency checking.
    - superdisk 1y ago
      I use Swift at my job, and all I can say is anecdotally we've had a ton of problems with memory safety. - Swift has a feature where you can unwrap a nullable which is basically just unusable, as it completely crashes the entire program if it fails, with no way for you to gracefully handle it or present a message to the user. And it's a massive footgun, since it has such convenient syntax that makes it seem like it should be used. But no, you have to avoid to like the plague. - There are some Apple APIs where they just disregard their own types, and pass nil to your callback where the type says it's non nullable. This means if you access the var at all, crash. - Concurrent access of dictionary, crash. And very hard to track down why as well since it can be very intermittent; in our case we were using an asynchronous dispatch queue instead of a sync one, so a single keyword. Oops! - Stack overflow, crash. - This isn't really Swift's fault, but in general every single macOS API is riddled with bugs and undocumented behavior. As a matter of fact, I would venture to say that almost every macOS API is virtually undocumented, either since there is literally no documentation or the existing documentation is just names of functions and occasionally an extremely out of date sample app. So IMO it's about as memory safe as C. We're floating around the idea of just porting everything to Rust and moving on, haven't researched or committed to it yet though.