NSO Zero-Click Malware Pwns Your iPhone With A Virtual CPU Encoded In Y2K Image Tech
If you're a technology enthusiast, you've probably heard of "one-click" malware. This is pretty scary stuff in its own right: one click of a carefully-crafted link in an e-mail or other text message, and you're infected. One-click malware has been around a long time, but there's something even worse these days. It's zero-click malware and that's exactly what the NSO Group's "FORCEDENTRY" exploit was.
FORCEDENTRY is likely the exploit used to attack the iPhones of nine US State Department employees in Uganda. It also seems like it was already in use during the global Pegasus spyware campaign earlier this year. The specific hole that the exploit used has been closed thanks to an Apple update in September, but details of exactly how the exploit worked are only just now coming to light thanks to a blog post from Google's Project Zero. Even if you're not an iPhone user, strap on your helmet, because this one's about to head into the weeds.
What makes this story so fascinating is how the exploit actually worked. On the surface, it's easy to say that the attackers sent a fake GIF that allowed them to gain remote code execution. That grossly undersells the sophistication of this hack, though. The "fake GIF" was in fact a PDF. PDFs can contain Javascript, and unsanitized execution of Javascript in PDFs was behind numerous PDF-related exploits in years past.
That's not what happened here. Instead, the PDF contained a data stream in JBIG2 format. JBIG2 is a little-known image format from 2000 that was created for fax machines and scanners. Rather than compressing image data like JPEG, JBIG2 attempts to intelligently compress documents by replacing every instance of similar glyphs (that is, individual characters) with a single instance of each glyph. It's not doing OCR; it doesn't understand that the images are text. The algorithm is just seeking out similar-looking characters and replacing them with the first instance of that character.
So how do you get from "parsing an image for display" to "full-on remote code execution?" The devil is in the details of how the JBIG2 format works. JBIG2 has problems as a compression format. Documents scanned into the JBIG2 format can have characters replaced with similar-looking characters, like a 6 being turned into an 8, for example, which is a real problem for things like medical documents or construction blueprints. That issue led to it being banned in Germany and Switzerland. JBIG2 does have lossless and "less-lossy" formats, though, and it's the latter of those which led to this security hole.
As part of the less-lossy JBIG2 format, streams can contain instructions to manipulate the image data using logical operators, like AND, OR, XOR, or XNOR. Using these operators, you can easily form a NAND gate, which means you can perform any computing operation imaginable, but JBIG2 is a linear format—the Apple image parser is going to read out the data stream once and only once.
Constructing a NAND gate from AND and NOR gates. Image: Project Zero
The way you get around this is by exploiting a plain-jane buffer overflow vulnerability in the open-source Xpdf library that Apple uses to decode PDFs. This buffer overflow is the crux of the exploit, but it's not the clever part. After performing the buffer overflow, the JBIG2 stream is free to write to arbitrary memory. Using the binary operations built into the JBIG2 format, the hackers construct a small virtual CPU in the phone's memory, and then use that to escape Apple's sandbox and pwn the phone.
In case it isn't clear, let's say it again: the JBIG2 format lacks scripting abilities, but combined with the buffer overflow flaw in Xpdf, it has the ability to "emulate circuits of arbitrary logic gates operating on arbitrary memory." They can't run code within a JBIG2 image, but they can create a virtual processor in RAM and then run code on that processor.
In the words of Google, the hackers "define a small computer architecture with features such as registers and a full 64-bit adder and comparator, which they use to search memory and perform arithmetic operations." The post continues, saying, "it's not as fast as Javascript, but it's fundamentally computationally equivalent," and it's all generated from a single decompression pass through a JBIG2 image data stream.
Project Zero hasn't explained the details of how the virtual processor's operations escape Apple's sandbox around the image transcoding process, but whatever that exploit is, it's almost certainly not as incredible as what the hackers did to get that far in the first place.
