In a Washington Post article about the Pegasus spyware, they say:
How can this infect a phone merely by sending a message? I expect this may be highly protected information but surely there are experts with educated guesses about how this works even if Pegasus itself is maximally confidential.
I don’t know anything about iPhone spyware specifically, but generally a “zero click” attack will exploit some bug in software that handles the data they are sending. Rather than getting the user to do something they shouldn’t, they get the program to do something it wasn’t designed to do.
For example, there’s the classic buffer overflow bug. That’s one where you get the program to write outside of its allotted memory by sending more data than it can handle. Ideally, the software should notice that you’ve sent too much data, but sometimes you can get it to not notice and it just keeps on writing to memory and gets into the part of memory that tells the computer what to do.
The oldest type of “no-click” attacks were called worms. They would exploit a flaw in Internet software to get them to send a copy of the worm to others. They didn’t require any user interaction. Reading up on Internet worms might make this make a bit more sense to you.
I am familiar with buffer overflow exploits. I am familiar with the concept of worms but not the innards and workings. I just never heard of an exploit where you can install software in a phone merely by sending a text message. I would think that text messaging is a simple application but I suppose it gets complicated when you peel the onion. I understand basics of TCP/IP but do not know how SMS works on the mobile network. I would also expect that Apple has some bells and whistles if you are going from Apple-to-Apple that are not available in standard SMS, like the ability to “like” a message and have that “like” visible to the sender, and maybe notify the sender if a message has been seen (I do not live in the Appleverse).
Attacks like this can only really be talked about in the past tense. As soon as the maker of the software finds out about it, they’re going to patch up the vulnerability that made it possible. So they only exist in the wild for the span of time that it takes for the company to learn of them and implement the fix, and the more successful the attack is, the quicker the company will learn of it.
This is especially true of devices like phones, that are constantly connected to a network over which they can receive updates, and they’re generally set up with permissions such that the user can’t refuse updates.
Maybe the iPhone is generating a preview of a picture, video, or other attachment as soon as it’s received (before any views happen) and the preview function has a bug in it that can be exploited?
Just seeing the wrong Wi-Fi name can/could hurt an iPhone.
Yeah, that generally agrees with my thoughts on this. There’s something in the SMS system that is examining every message as it comes in that is striking out when it comes to validating the data it’s taking in (size? sanitation? who knows?). Someone’s figured out how to use that lack of validation to escape the process it’s in and ends up getting to run arbitrary code.
Recall that Windows a while ago had a bug in the JPEG process where a specifically malformed JPG file could cause the PC to begin executing the embedded code.
Presumably, this is what Pegasus was doing - send a text via iMessage which included a picture or some other file, and before the iMessage system finished processing (and so registered a text had been received) it had invoked the processor for that file type which failed and caused the code to execute. Presumably (IANA iphone expert) as, say, iPhone detects an incoming JPG or PNG or HEIC or video or whatever, it will invoke some part of the iOS that will at least add the content to a library, so it is recognized as not a string of text.
Some item I heard about Pegasus suggested there were several exploits they knew about, and the process was to try some of these and see if the exploit worked. Any patch simply reduced the number of options to try. Also, the code executed has been updated - suggesting to avoid detection, the newer version resides only in volatile RAM and would disappear (and need to be re-sent) if the phone were powered down.