Google Project Zero researcher Natalie Silvanovich has just published a
fascinating blog articleentitled
The Fully Remote Attack Surface of the iPhone.
This work, carried out by Silvanovich and research colleague Samuel Groß, was also the topic of a presentation she gave at this year’s Black Hat conference in Las Vegas.
Silvanovich’s article is technical but not overly so, making it well worth a look even if you don’t have any formal coding experience.
Notably, she reminds us all how easy it is to open up software to remote attacks, even if that software isn’t what you’d conventionally think of as server-side code, and even if it’s running on a device that you wouldn’t think of a server.
By the way, despite the revelatory nature of the article and her talk, there’s no need to panic.
At least, you don’t need to be too worried if you’ve already applied the latest Apple updates, because the holes that Silvanovich is now talking about in detail are already patched.
If you haven’t brought your iPhone up to iOS 12.4 yet, do it now!
Settings → General → Software Update is the quick way to check.
To explain.
An exploit that gives RCE, short for remote code execution, does exactly what its name suggests – by doing something unexceptionable, and without seeing any warnings, even well-informed users can be tricked into giving crooks access to their device.
A fully remotable exploit is even worse, because there’s no need for users to do anything except have their devices turned on and running normally.
LEARN MORE ABOUT VULNERABILITIES
A booby-trapped website that crashes and takes over your browser gives the crooks RCE.
Likewise, before Microsoft turned off AutoRun by default for USB devices, the proverbial USB-stick-in-the-card-park attack was considered a reliable way to achieve RCE because the chosen malware typically launched as soon as someone plugged in the booby-trapped USB key.
There wasn’t any sort of Are you sure? or [Cancel]/[OK] popup to sound a warning and give you a chance to head off the malware.
But even though visiting a web page or plugging in a USB device isn’t a difficult bridge for crooks to talk you into crossing, those attacks aren’t quite the holy grail of RCE, because some user engagement is needed.
A fully remote attack “just happens”, like the infamous
Internet Worm of 1988, or the super-widespread
SQL Slammer virus of 2003.
Those attacks sent network data that your computer was deliberately listening out for – no trickery required to get a foot in the door – but that your computer mishandled.
This allowed the crooks to package executable code inside their data packets and to achieve RCE in an entirely unattended and automatic way.
One of the Internet Worm’s attack methods, for example, exploited badly-configured email servers on which debugging mode was incorrectly enabled.
If you’d inadvertently left the debug option turned on, emails laid out in a certain way were treated as commands to execute (!), not as messages to be passed on, so the email server ran the malware immediately after accepting it.
The worm’s emails were directly dangerous without any user ever needing to receive them, let alone to open them or extract and run attachments from them.
Phones ≠ Servers
You might imagine that devices such as mobile phones, which generally don’t operate as servers themselves, would largely be immune to this sort of fully remote attack.
After all, you don’t generally run a mail server or a SQL server on your phone, and even if you wanted to, Apple probably wouldn’t let that sort of software into the App Store.
Even if you were to jailbreak your phone to install server software, your ISP might not allow incoming network connections to reach your phone at all, even if you were willing to accept them.
But, as Silvanovich reminds us, phones are all about messaging, and there are many sorts of message that we expect to be told about even before they arrive in full.
(An incoming call is the most obvious example: we expect the phone to ring, and the calling line’s number to be extracted and displayed, not only before we tap any icon to accept the call but also even when our phone is at the lock screen.)
In other words, even though we think of phones as network clients rather than network servers, there are plenty of client-side apps that download, process, act upon and display data that came from an arbitrary outside source.
We’re not just talking about things like automatic software or anti-virus updates that come from a known, trusted and well-regulated service, but also about content such as text messages or emails that were carefully and maliciously crafted by an unknown, untrusted and deliberately malicious creator.
Silvanovich identified five main application areas of interest on the iPhone, covering iOS subsystems that are specifically designed to fetch, process and tell you about incoming content: SMS, MMS, Visual voicemail, email and iMessage.
In the end, the researchers didn’t find any exploitable holes in SMS or MMS, perhaps because these subsystems are rather old-school and therefore have functionality that is both well-understood and somewhat limited.
But the others weren’t so robust.
As you can imagine, the more features, the more message types, the more different options, the more plugins and the more file formats an app suports, the more likely it is for a bug to exist in handling unusual, little-known or malevolently crafted files.
For example, you’d expect image processing software that can only display old-school BMP files (simple structure and plain, uncompressed data) to be less likely to crash on weird files than software that can handle 72 different image files with varying levels of complexity.
The more code you need to write to process incoming data and to handle all the possible variations, the harder it is to get it right; the harder it is test throroughly; the more likely it is to contain
subtle bugs; and the longer it will take for every possible path through the maze of code to get tried out when handling real data in the real world.
Simply put, we say that its attack surface area is larger.
More code, more bugs
Although Silvanovich and Groß did find vulnerabilities in Visual voicemail and in the iOS’s email-handling system, these weren’t terribly significant.
But via iMessage they found at least eight security holes, listed by their CVE numbers: CVE-2019-8624, -8663,-8661, -8646, -8647, -8662, -8641 and -8660. (That’s the order in which they are covered in the article, which is why they are not in numeric sequence here.)
Note that even though Apple lists
CVE-2019-8661 as patched in its latest iOS security advisory, the Googlers haven’t disclosed details of this one yet because they don’t think Apple’s update has fully fixed the problem yet.
What to do?
- Get the latest iOS update if you haven’t yet. Many or most of the bug numbers listed above become irrelevant once you’ve applied the patches.
- Get the next update as soon as it comes out. It sounds as though Apple is still working on CVE-2019-8661, and that Google is giving the company some more time to knock the bug on the head completely.
- Less is more. If you are a programmer yourself, beware of writing code that does more than it needs to, or that itself depends on so many other modules or plugins that you can’t easily vouch for the whole thing, no matter how confident you are that your code is bug-free.
