6 ms·

To me the key question is: Why is iMessage not a normal iOS app? We've seen numerous iMessage bugs over the years inc. full OS take-overs (often used for jailb

To me the key question is: Why is iMessage not a normal iOS app? We've seen numerous iMessage bugs over the years inc. full OS take-overs (often used for jailbreak), soft bricking (endless restarts due to corrupt notifications/requiring a factory reset), crashes that reboot the phone (once), and a bunch of potential for escalation/code execution. None of this is possible with apps in the normal iOS sandbox. The apps themselves would crash, but they're context confined, they cannot bring down the underlying OS, write invalid notifications, or cause a kernel panic. But they've designed iMessage to act like a part of the underlying OS for no real reason. You could very easily hand off the most hazardous parts of iMessage's inner workings into the app's context, or even another user space/context confined service, and just let them crash like normal apps do. Ten years ago it was common for font processing to happen in the kernel. This was problematic because front processing is hard, and bugs occur. Since then we've seen many migrate fonts into userland. Why is iMessage's security model so far behind the times, it is a lot less critical/performance impacted than fonts, but yet has worse security than most font systems in 2019?

colejohnson66 7y ago
Maybe because they want to integrate it with the Messages app so it’s used without having to worry about it? Could they still keep it integrated and put it in userland?
csande17 7y ago
I suspect it's because historically, iOS didn't have a way to embed views from one app into another app. When Apple wanted to let you view iMessages from the lock screen, or expose iMessage via Share buttons in third-party apps, they accomplished that by shoving most of iMessage into the operating system itself. These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.
- ksahin 7y ago
  > These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created. You made my day thanks !
- saagarjha 7y ago
  FWIW, the iMessage shortlook on the lock screen and share sheet are both run out-of-process and embedded in their hosting applications as remote views. I believe the latter has actually been separate all the way back to iOS 6.
- devin 7y ago
  >small indie company that does not have the resources. Can we be friends? This is incredible.
  - ludamad 7y ago
    "small indie company" is a frequent meme by disgruntled gamers
    - zapzupnz 7y ago
      Especially fans of Pokémon who aren't fans of Game Freak, lately.
- heed 7y ago
  Honestly it would probably be easier to do a refactor like this if they were a small company. There are a lot barriers and things move slowly at large companies.
  - notyourwork 7y ago
    Yes a few product managers debating adding new whimsical features.
    - WrtCdEvrydy 7y ago
      The hardest part of refactoring is selling people on the upsides of creating something that does the same thing the previous thing did...
      - zuppy 7y ago
        it actually will do less, though, as it will most probably introduce new bugs
saagarjha 7y ago
iMessage is a normal iOS app, at least mostly. It has access to a couple of entitlements that normal apps don't get, since it needs to do things like access Apple Pay and launch iMessage apps, but it's possible to have the app itself crash without hosing the entire OS. The problems we're seeing here, however, are issues where iMessage's (buggy) frameworks are being loaded into the SpringBoard process (which is essentially the UI shell for iOS) and this is what is crashing, causing the phone to be unusable. So the solution here would be to stop allowing for message parsing to happen in contexts like these. (Also, as far as I am aware, there have not been any jailbreaks in iMessage that rely on the app being special in any particular way because it's really not.)
- JBiserkov 7y ago
  Internet Explorer is a normal Windows application, at least mostly. It has access to a couple of entitlements that normal applications don't get, since it needs to do things like access MSN Passport and launch ActiveX components, but it's possible to have the app itself crash without hosing the entire OS. The problems we're seeing here, however, are issues where Internet Explorer's (buggy) frameworks are being loaded into the Explorer.exe process (which is essentially the UI shell for Windows) and this is what is crashing, causing the computer to be unusable. 2002 called.
  - saagarjha 7y ago
    The difference being that with iMessage people can trigger the bug remotely and there's little you can do about it except turn it off completely (as someone I know did end up doing). Hey, I didn't say that what they were doing was a good idea :)
    - sambe 7y ago
      Internet Explorer bugs could not be triggered remotely?
      - noisem4ker 7y ago
eridius 7y ago
Ultimately I think the question is "why does iMessages have special integration in SpringBoard"? Because that's the cause of most of this. Messages doesn't have to be a "normal iOS app", it just has to be reasonably sandboxed. Running code using adversarial input inside SpringBoard is a serious problem.
- derefr 7y ago
  A key thing to know is that SMSes do other things than just hand text to a program to display it. There is, for example, Flash (Class 0) SMS, which has the semantics that it both: 1. must display over whatever the user is doing (sort of like a Windows elevation prompt) and 2. must not be handed to userland in a way that it could be automatically recorded or persisted, other than by the user's explicit action. Giving SpringBoard the ability to render SMSes is really the only way to implement Flash SMS in a way that adheres to its semantics. There are other types of SMSes as well—WAP Push messages, for example, or WMI (voicemail indicator) Activation messages. Heck, your carrier can even use SMSes to directly write data to your SIM card. These aren't so clearly a layering violation as Flash SMS, as they are just pure OS-layer concerns; but if you're already implementing a kernel library for "SMSes triggering OS-level functionality" for Flash SMS and the like, you may as well put the code to handle these cases in there as well.
  - eridius 7y ago
    Ok, but that just means SpringBoard (or some other system component) has to parse SMS messages. It doesn't mean SpringBoard has to be involved in the display of texts, and it also doesn't mean it has to be involved in iMessages. The moment SpringBoard determines that an SMS doesn't fall into the class of things that must be handled by the OS, it should stop and hand it over to the Messages app to do the rest of the parsing.
    - saagarjha 7y ago
      Or spawn an XPC service.
    - eridius 7y ago
lowdose 7y ago
You are spot on "practice what you preach".

colejohnson66 7y ago

Maybe because they want to integrate it with the Messages app so it’s used without having to worry about it? Could they still keep it integrated and put it in userland?

csande17 7y ago

I suspect it's because historically, iOS didn't have a way to embed views from one app into another app. When Apple wanted to let you view iMessages from the lock screen, or expose iMessage via Share buttons in third-party apps, they accomplished that by shoving most of iMessage into the operating system itself. These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created.

ksahin 7y ago
> These days, there are systems to do this properly (it's how third-party keyboards work, for example), but Apple is a small indie company that does not have the resources to refactor iMessage to use the iOS features they created. You made my day thanks !
saagarjha 7y ago
FWIW, the iMessage shortlook on the lock screen and share sheet are both run out-of-process and embedded in their hosting applications as remote views. I believe the latter has actually been separate all the way back to iOS 6.
devin 7y ago
>small indie company that does not have the resources. Can we be friends? This is incredible.
- ludamad 7y ago
  "small indie company" is a frequent meme by disgruntled gamers
  - zapzupnz 7y ago
    Especially fans of Pokémon who aren't fans of Game Freak, lately.
heed 7y ago
Honestly it would probably be easier to do a refactor like this if they were a small company. There are a lot barriers and things move slowly at large companies.
- notyourwork 7y ago
  Yes a few product managers debating adding new whimsical features.
  - WrtCdEvrydy 7y ago
    The hardest part of refactoring is selling people on the upsides of creating something that does the same thing the previous thing did...
    - zuppy 7y ago
      it actually will do less, though, as it will most probably introduce new bugs

saagarjha 7y ago

iMessage is a normal iOS app, at least mostly. It has access to a couple of entitlements that normal apps don't get, since it needs to do things like access Apple Pay and launch iMessage apps, but it's possible to have the app itself crash without hosing the entire OS. The problems we're seeing here, however, are issues where iMessage's (buggy) frameworks are being loaded into the SpringBoard process (which is essentially the UI shell for iOS) and this is what is crashing, causing the phone to be unusable. So the solution here would be to stop allowing for message parsing to happen in contexts like these. (Also, as far as I am aware, there have not been any jailbreaks in iMessage that rely on the app being special in any particular way because it's really not.)

JBiserkov 7y ago
Internet Explorer is a normal Windows application, at least mostly. It has access to a couple of entitlements that normal applications don't get, since it needs to do things like access MSN Passport and launch ActiveX components, but it's possible to have the app itself crash without hosing the entire OS. The problems we're seeing here, however, are issues where Internet Explorer's (buggy) frameworks are being loaded into the Explorer.exe process (which is essentially the UI shell for Windows) and this is what is crashing, causing the computer to be unusable. 2002 called.
- saagarjha 7y ago
  The difference being that with iMessage people can trigger the bug remotely and there's little you can do about it except turn it off completely (as someone I know did end up doing). Hey, I didn't say that what they were doing was a good idea :)
  - sambe 7y ago
    Internet Explorer bugs could not be triggered remotely?
    - noisem4ker 7y ago

eridius 7y ago

Ultimately I think the question is "why does iMessages have special integration in SpringBoard"? Because that's the cause of most of this. Messages doesn't have to be a "normal iOS app", it just has to be reasonably sandboxed. Running code using adversarial input inside SpringBoard is a serious problem.

derefr 7y ago
A key thing to know is that SMSes do other things than just hand text to a program to display it. There is, for example, Flash (Class 0) SMS, which has the semantics that it both: 1. must display over whatever the user is doing (sort of like a Windows elevation prompt) and 2. must not be handed to userland in a way that it could be automatically recorded or persisted, other than by the user's explicit action. Giving SpringBoard the ability to render SMSes is really the only way to implement Flash SMS in a way that adheres to its semantics. There are other types of SMSes as well—WAP Push messages, for example, or WMI (voicemail indicator) Activation messages. Heck, your carrier can even use SMSes to directly write data to your SIM card. These aren't so clearly a layering violation as Flash SMS, as they are just pure OS-layer concerns; but if you're already implementing a kernel library for "SMSes triggering OS-level functionality" for Flash SMS and the like, you may as well put the code to handle these cases in there as well.
- eridius 7y ago
  Ok, but that just means SpringBoard (or some other system component) has to parse SMS messages. It doesn't mean SpringBoard has to be involved in the display of texts, and it also doesn't mean it has to be involved in iMessages. The moment SpringBoard determines that an SMS doesn't fall into the class of things that must be handled by the OS, it should stop and hand it over to the Messages app to do the rest of the parsing.
  - saagarjha 7y ago
    Or spawn an XPC service.
  - eridius 7y ago

lowdose 7y ago

You are spot on "practice what you preach".