5 ms·

I got corrected last time this topic came up. I originally thought Messages was part of the OS and not a pre-installed userspace app. However, if it's in usersp

I got corrected last time this topic came up. I originally thought Messages was part of the OS and not a pre-installed userspace app. However, if it's in userspace, why is it such a vulnerable vector for compromising the phone? Is there some privilege-escalation component to this that I haven't read about?

saagarjha 5y ago
iMessage is a pre-installed userspace app that uses frameworks that ship with the OS.
dannyw 5y ago
iMessage is one of few apps that have broad permissions to execute code in response to notifications. For other apps like Telegram; the server can send a predefined notification message. For iMessage, when you get something even from someone outside your contacts, its daemon invokes specific code to handle the message, and its attachments. Whilst this doesn't help if someone opens the app, it does at least change this from a zero click attack, to a one click attack. (This is also another example of Apple not following its own app store rules. It has privileged access to frameworks.)
- eloisius 5y ago
  So, in theory other messaging apps have the same vulnerabilities, but I’d have to open the message to get burnt?
  - dannyw 5y ago
    Yes. These apps also have happened to WhatsApp.
    - eloisius 5y ago
      Still hard to understand. If it’s just image preview code, why isn’t Safari vulnerable?
      - saagarjha 5y ago
        It might be, it’s just that using Safari would turn a zero-click attack into a one-click one (click on my shady link). (Also, WebKit runs with a different sandbox that may require special effort to escape out of.)
      - t0ps0il 5y ago
        It's not exactly specific to the image preview code, but rather the code that handles the notification when receiving an iMessage. The attack mentioned in the Wired article[1] relies on iMessage asking the sandboxless Springboard[2][3] to deserialize a maliciously crafted field, included in the incoming iMessage, to escape the sandbox. This specific vulnerability doesn't appear to apply to other apps. [1] https://googleprojectzero.blogspot.com/2019/08/the-fully-remote-attack-surface-of.html https://googleprojectzero.blogspot.com/2019/08/the-fully-rem... [2] https://en.wikipedia.org/wiki/SpringBoard https://en.wikipedia.org/wiki/SpringBoard [3] https://iphonedev.wiki/index.php/SpringBoard https://iphonedev.wiki/index.php/SpringBoard
  - t0ps0il 5y ago
    No. This attack is specific to iMessage, since iMessage can access the springboard (the singleton class, not Springboad.app), while apps downloaded from the App Store cannot.
- saagarjha 5y ago
  This is not true. With the right setup, you can send a push notification to your app to wake it up and execute code. See this delegate method for example: https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623013-application https://developer.apple.com/documentation/uikit/uiapplicatio....
- simondotau 5y ago
  A bit off topic, but when did we ever expect integrated apps to be restricted to App Store rules? They're literally sold as part of the device, not as an app through the App Store.

saagarjha 5y ago

iMessage is a pre-installed userspace app that uses frameworks that ship with the OS.

dannyw 5y ago

iMessage is one of few apps that have broad permissions to execute code in response to notifications. For other apps like Telegram; the server can send a predefined notification message. For iMessage, when you get something even from someone outside your contacts, its daemon invokes specific code to handle the message, and its attachments. Whilst this doesn't help if someone opens the app, it does at least change this from a zero click attack, to a one click attack. (This is also another example of Apple not following its own app store rules. It has privileged access to frameworks.)

eloisius 5y ago
So, in theory other messaging apps have the same vulnerabilities, but I’d have to open the message to get burnt?
- dannyw 5y ago
  Yes. These apps also have happened to WhatsApp.
  - eloisius 5y ago
    Still hard to understand. If it’s just image preview code, why isn’t Safari vulnerable?
    - saagarjha 5y ago
      It might be, it’s just that using Safari would turn a zero-click attack into a one-click one (click on my shady link). (Also, WebKit runs with a different sandbox that may require special effort to escape out of.)
    - t0ps0il 5y ago
      It's not exactly specific to the image preview code, but rather the code that handles the notification when receiving an iMessage. The attack mentioned in the Wired article[1] relies on iMessage asking the sandboxless Springboard[2][3] to deserialize a maliciously crafted field, included in the incoming iMessage, to escape the sandbox. This specific vulnerability doesn't appear to apply to other apps. [1] https://googleprojectzero.blogspot.com/2019/08/the-fully-remote-attack-surface-of.html https://googleprojectzero.blogspot.com/2019/08/the-fully-rem... [2] https://en.wikipedia.org/wiki/SpringBoard https://en.wikipedia.org/wiki/SpringBoard [3] https://iphonedev.wiki/index.php/SpringBoard https://iphonedev.wiki/index.php/SpringBoard
- t0ps0il 5y ago
  No. This attack is specific to iMessage, since iMessage can access the springboard (the singleton class, not Springboad.app), while apps downloaded from the App Store cannot.
saagarjha 5y ago
This is not true. With the right setup, you can send a push notification to your app to wake it up and execute code. See this delegate method for example: https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623013-application https://developer.apple.com/documentation/uikit/uiapplicatio....
simondotau 5y ago
A bit off topic, but when did we ever expect integrated apps to be restricted to App Store rules? They're literally sold as part of the device, not as an app through the App Store.