7 ms·

How many exploits has iMessage had now? Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted

How many exploits has iMessage had now? Isn't it time we made first messages from all new contacts plain text only, and all other messages some very restricted subset rather than some crazy extensible system that isn't so different from ActiveX? And on top of that, maybe the whole app should run in a sandbox. And on top of that, perhaps it should all be a webview to give one more layer of protection.

DanHulton 3y ago
On plain text -- in short, it doesn't exist: https://www.youtube.com/watch?v=gd5uJ7Nlvvo https://www.youtube.com/watch?v=gd5uJ7Nlvvo And there have definitely been UTF-8 parsing bugs before and likely will again.
doug_durham 3y ago
Every process in iOS is run in a sandbox. That is why these exploits are so hard to come by.
- markus_zhang 3y ago
  I so respect those who figured out these exploits. I don't like people using them of course but the technical brilliance is indisputable.
callalex 3y ago
There is even precedent for doing this seamlessly: the Apple Mail client will not render media from unknown senders without user confirmation. iMessage should have the exact same behavior for the same reasons. It’s frustrating to watch greedy project managers re-learning the exact same lessons that a previous generation already learned the hard way, especially when they all work in the same building.
- cozzyd 3y ago
  This is for a different reason (all useful e-mail clients do the same thing!). If Mail (or thunderbird or whatever) loaded the media, then the sender could know you opened the e-mail (by sending each recipient a unique image), leaking information.
- saagarjha 3y ago
  This is how Lockdown Mode works.
  - jmprspret 3y ago
    This should be the default. It is the default on apple mail from what I'm reading, so why not the I message app?
    - saagarjha 3y ago
      Mail does this for privacy, not security. Emails can load remote content and this can be used to track you. This is not generally true of images sent in iMessage because they get sent directly.
- deleted 3y ago
  [deleted]
- organsnyder 3y ago
  Does the Apple Mail client do this for images included with the message (instead of referencing by URL)? Like another comment mentions, this is done for other reasons, and many clients render embedded images by default.
seanhunter 3y ago
This is very different from ActiveX. ActiveX had hundreds of exploits widely available freely on the dark parts of usenet, and exploited by every proverbial scriptkiddie in a basement against a swath of computers across the world. iMessage has had a handful of exploits which are licensed out for extortionate amounts by people like NSO to a very small number of scummy nationstate threat actors in extremely targetted but very high-threat attacks on very high-profile targets.
- bt1a 3y ago
  You don't know how many exploits iMessage has.
  - saberience 3y ago
    How many does it have?
    - offices 3y ago
      Unknowable
      - JTon 3y ago
        True but a useless fact. One way to interpret u/seanhunter's comment is to make the comparison between imessage and activex in the known exploit space and then extrapolate into the unknown space assuming equal proportions. Seems reasonable to me.
- oasisaimlessly 3y ago
  All that's different now is that the script kiddies have grown up.
  - seanhunter 3y ago
    I really don't think that's true - the state of appsec and security awareness in general has really improved a lot, and all of the major platforms (windows included) are much much more secure now by default than in the activeX era. It's definitely not the case that anyone can just throw together an iPhone zeroday, which is why the price of these exploits is so much higher.
MuffinFlavored 3y ago
What's not clear to me is given all of the layers/security features Apple has, say you are able to get an iMessage exploit where you can run code... you can't access the file system/cache of other apps (like your banking app to get cookies/tokens), can you?
- deleted 3y ago
  [deleted]
- ghughes 3y ago
  Not directly, but now you can exploit vulnerabilities in other parts of the OS.
baby 3y ago
can one actually disable iMessage on their iPhones? At this point I only use WhatsApp, I couldn't care less about super SMS. EDIT: found it. For anyone who's interested: > Turn off iMessage: > On your iPhone, go to Settings. > Tap Messages. > Set iMessage to Off.
- dikei 3y ago
  It seems that even turning off iMessage is not enough ? This a zero-click exploit, which means you don't even have to open the message to get hacked.
  - CommitSyn 3y ago
    It means it runs through iMessage. Whether the "turn off iMessage" feature is enough I don't know. But if turning off iMessage actually stops any messages and SMS/MMS etc from running through iMessage at all, it's a pretty decent bet.
alkonaut 3y ago
Yeah I can't believe we are still seeing this happen over and over again. Whenever you see "zero click" you know it's one of the complex payloads like images, fonts. The answer shouldn't be "don't render images". We should be able to trust that a component that parses external data such as an image, simply can't do anything malicious regardless of input. If that means sandboxing, fine. If it means having to rewrite all the image parsers from the ground up in a safe language or formally prove them correct, fine. Just get on with it. Apple is rich enough to be able to run their own space program ten times over, I think they could write provably correct imaging libs too.
- brigade 3y ago
  Yes parsers are already sandboxed, and violating the sandbox boundary is where the actual valuable exploit is. Parser vulns are near worthless without the rest of the chain building on it, and the millions of man-years it would take to re-write every last one of them as "provably correct" is better spent hardening sandbox and privilege boundaries. Which is a completely different problem than simply rewriting things in a safe language.
  - alkonaut 3y ago
    What is the cause of the sandbox escape in this case? Somewhere (too high in the stack) there is a C-ish program where someone does pointer arithmetic or an array deref in C which is the same thing.
    - brigade 3y ago
      Are you asking what the full exploit chain is here specifically? Because that obviously hasn't been written up yet. But for the last one, it's the difference between https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... (parser vulnerability leading to not-really arbitrary code execution and memory corruption) and https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html https://googleprojectzero.blogspot.com/2022/03/forcedentry-s... (logic errors leading to a sandbox escape) Notably, the sandbox escape itself did not do anything that would have been prevented by a memory safe language. The security model of a sandboxed process is that even full arbitrary code execution cannot do anything the sandbox says the process cannot do, and the process the parsers run in is sandboxed to only be able to communicate to other processes through very limited interfaces that have no access to network or disk.
ghughes 3y ago
Then they'll exploit the webview followed by the sandbox. [1] As of iOS 14, incoming messages are parsed in a tight sandbox [2]. It'll be interesting to hear how this attack got around that. [1] https://en.wikipedia.org/wiki/JailbreakMe https://en.wikipedia.org/wiki/JailbreakMe [2] https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...

DanHulton 3y ago

On plain text -- in short, it doesn't exist: https://www.youtube.com/watch?v=gd5uJ7Nlvvo https://www.youtube.com/watch?v=gd5uJ7Nlvvo And there have definitely been UTF-8 parsing bugs before and likely will again.

doug_durham 3y ago

Every process in iOS is run in a sandbox. That is why these exploits are so hard to come by.

markus_zhang 3y ago
I so respect those who figured out these exploits. I don't like people using them of course but the technical brilliance is indisputable.

callalex 3y ago

There is even precedent for doing this seamlessly: the Apple Mail client will not render media from unknown senders without user confirmation. iMessage should have the exact same behavior for the same reasons. It’s frustrating to watch greedy project managers re-learning the exact same lessons that a previous generation already learned the hard way, especially when they all work in the same building.

cozzyd 3y ago
This is for a different reason (all useful e-mail clients do the same thing!). If Mail (or thunderbird or whatever) loaded the media, then the sender could know you opened the e-mail (by sending each recipient a unique image), leaking information.
saagarjha 3y ago
This is how Lockdown Mode works.
- jmprspret 3y ago
  This should be the default. It is the default on apple mail from what I'm reading, so why not the I message app?
  - saagarjha 3y ago
    Mail does this for privacy, not security. Emails can load remote content and this can be used to track you. This is not generally true of images sent in iMessage because they get sent directly.
deleted 3y ago
[deleted]
organsnyder 3y ago
Does the Apple Mail client do this for images included with the message (instead of referencing by URL)? Like another comment mentions, this is done for other reasons, and many clients render embedded images by default.

seanhunter 3y ago

This is very different from ActiveX. ActiveX had hundreds of exploits widely available freely on the dark parts of usenet, and exploited by every proverbial scriptkiddie in a basement against a swath of computers across the world. iMessage has had a handful of exploits which are licensed out for extortionate amounts by people like NSO to a very small number of scummy nationstate threat actors in extremely targetted but very high-threat attacks on very high-profile targets.

bt1a 3y ago
You don't know how many exploits iMessage has.
- saberience 3y ago
  How many does it have?
  - offices 3y ago
    Unknowable
    - JTon 3y ago
      True but a useless fact. One way to interpret u/seanhunter's comment is to make the comparison between imessage and activex in the known exploit space and then extrapolate into the unknown space assuming equal proportions. Seems reasonable to me.
oasisaimlessly 3y ago
All that's different now is that the script kiddies have grown up.
- seanhunter 3y ago
  I really don't think that's true - the state of appsec and security awareness in general has really improved a lot, and all of the major platforms (windows included) are much much more secure now by default than in the activeX era. It's definitely not the case that anyone can just throw together an iPhone zeroday, which is why the price of these exploits is so much higher.

MuffinFlavored 3y ago

What's not clear to me is given all of the layers/security features Apple has, say you are able to get an iMessage exploit where you can run code... you can't access the file system/cache of other apps (like your banking app to get cookies/tokens), can you?

deleted 3y ago
[deleted]
ghughes 3y ago
Not directly, but now you can exploit vulnerabilities in other parts of the OS.

baby 3y ago

can one actually disable iMessage on their iPhones? At this point I only use WhatsApp, I couldn't care less about super SMS. EDIT: found it. For anyone who's interested: > Turn off iMessage: > On your iPhone, go to Settings. > Tap Messages. > Set iMessage to Off.

dikei 3y ago
It seems that even turning off iMessage is not enough ? This a zero-click exploit, which means you don't even have to open the message to get hacked.
- CommitSyn 3y ago
  It means it runs through iMessage. Whether the "turn off iMessage" feature is enough I don't know. But if turning off iMessage actually stops any messages and SMS/MMS etc from running through iMessage at all, it's a pretty decent bet.

alkonaut 3y ago

Yeah I can't believe we are still seeing this happen over and over again. Whenever you see "zero click" you know it's one of the complex payloads like images, fonts. The answer shouldn't be "don't render images". We should be able to trust that a component that parses external data such as an image, simply can't do anything malicious regardless of input. If that means sandboxing, fine. If it means having to rewrite all the image parsers from the ground up in a safe language or formally prove them correct, fine. Just get on with it. Apple is rich enough to be able to run their own space program ten times over, I think they could write provably correct imaging libs too.

brigade 3y ago
Yes parsers are already sandboxed, and violating the sandbox boundary is where the actual valuable exploit is. Parser vulns are near worthless without the rest of the chain building on it, and the millions of man-years it would take to re-write every last one of them as "provably correct" is better spent hardening sandbox and privilege boundaries. Which is a completely different problem than simply rewriting things in a safe language.
- alkonaut 3y ago
  What is the cause of the sandbox escape in this case? Somewhere (too high in the stack) there is a C-ish program where someone does pointer arithmetic or an array deref in C which is the same thing.
  - brigade 3y ago
    Are you asking what the full exploit chain is here specifically? Because that obviously hasn't been written up yet. But for the last one, it's the difference between https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i... (parser vulnerability leading to not-really arbitrary code execution and memory corruption) and https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html https://googleprojectzero.blogspot.com/2022/03/forcedentry-s... (logic errors leading to a sandbox escape) Notably, the sandbox escape itself did not do anything that would have been prevented by a memory safe language. The security model of a sandboxed process is that even full arbitrary code execution cannot do anything the sandbox says the process cannot do, and the process the parsers run in is sandboxed to only be able to communicate to other processes through very limited interfaces that have no access to network or disk.

ghughes 3y ago

Then they'll exploit the webview followed by the sandbox. [1] As of iOS 14, incoming messages are parsed in a tight sandbox [2]. It'll be interesting to hear how this attack got around that. [1] https://en.wikipedia.org/wiki/JailbreakMe https://en.wikipedia.org/wiki/JailbreakMe [2] https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...