Earlier this week, we advised iPhone users to waste no time applying the latest iOS update, even though it came out just five days after Apple’s previous, much bigger update.
(The week-before-last’s update was a 700MB blockbuster taking you to iOS 10.3; this week’s was a 30MB point release to 10.3.1.)
The story behind the iPhone 10.3.1 update, however, goes well beyond iPhones in particular, beyond iOS, and even well beyond Apple.
The bug that was fixed in iOS 10.3.1 was found and reported by Gal Beniamini of Google’s Project Zero, but it wasn’t a bug in iOS.
Some of Google’s own flagship phones were affected too – indeed, Beniamini used a Nexus 6P as his guinea pig device during the extensive (and very interestingly described) spelunking he performed while finding and exploiting the hole.
The bug isn’t in the the core operating system itself, such as Android or iOS, or in any of the apps that are installed, and the bug doesn’t even involve running unauthorised program code on the CPU of the device itself.
Instead, Beniamini decided to test the security of the various peripherals used, well, on the periphery of the device.
For example, if you think of a phone as a full-blooded computer, much like your laptop, then that phone is itself connected up to a whole raft of ancillary hardware, such as bluetooth adapters, webcams, cellular modems and Wi-Fi network cards that are essentially Internet of Things (IoT) devices in their own right.
In this research project, Beniamini decided to zoom in on Broadcom Wi-Fi hardware, implemented as what’s called an SoC, short for “system on chip”.
His motivations were straightforward: Broadcom devices are widely used; he could get his hands on technical documentation for the chips (albeit not of the most current versions); and several Google devices use them, including the Nexus 5, 6 and 6P models, so he had a handy supply of test kit, courtesy of his employer.
And, as he himself puts it:
Over the years, as a result of the focused attention by security folk, the defenses of code running on the application processor have been reinforced. [. . .] However, attackers tend to follow the path of least resistance. Improving the security of one component will inevitably cause some attackers to start looking elsewhere for an easier point of entry.
We’ve seen exactly this sort of “security gap” before when comparing desktop apps, such as browsers, which have had years of serious security attention, and mobile apps, which haven’t.
Pwning your Wi-Fi
Biniamini found several vulnerabilities in the Broadcom firmware he chose to look at, but one has hogged the news: CVE-2017-0561.
This bug is what’s known as a heap overflow vulnerability, where memory used by one part of the software tramples on memory used by another.
The heap is the jargon name given to a lump of memory that’s managed by the operating system, with blocks inside the heap allocated temporarily to a process at one point, and taken back when no longer needed.
Without a managed memory heap, every process would need to grab onto the maximum amount of memory it might ever need up front, just in case, which would be incredibly inefficient.
If you can trample process memory in just the right sort of way, you may be able to orchestrate the way the process misbehaves so that you can control what happens next, such as diverting the CPU’s flow of execution into the data in the buffer you just overflowed.
If you can do that, you’ve found a remote code execution (RCE) exploit: without logging in, or entering a password, or going through any other security check, you can take over and run a snippet of malicious software of your choice.
Those snippets of malicious software are known in the jargon as shellcode, where code means executable program instructions, and shell is a metaphor that comes from “command shell”, which is what a command prompt window is called in the Unix world.
Missed opportunities
Thanks to his detailed digging, Biniamini found three modern security practices that Broadcom hadn’t used in the firmware he analysed.
The first missed opportunity is what’s known variously as heap cookies, heap canaries, or safe unlinking.
Simply put, modern operating systems perform all sorts of additional checks when allocating and deallocating heap memory, for example by placing a randomly-chosen data value between the memory blocks that are dished out for use.
This doesn’t stop buffer overflows, and it doesn’t prevent them being exploitable, but it makes the task much harder, and it means that even if an attack can’t be stopped outright, it can often be detected very quickly and mitigated.
Every time the system memory manager is triggered, it can run through the list of allocated memory blocks to look for corruption, such as evidence that the tell-tale marker at the end of each block hasn’t been trampled on, which is almost inevitable in the event of a buffer overflow.
The name “heap canary” comes from the canary that coal miners used to take underground. A canary would faint in the presence of the explosive mine gas methane and fall off its perch, signalling that the shaft was dangerous.
The second missed opportunity is what’s known on Windows as data execution prevention, or DEP for short.
That means using features in the CPU itself to denote which parts of memory contain data, rather than code.
That way, any attempt – accidental or deliberate – to execute code from a location where data was expected can be detected, reported and blocked.
DEP makes heap overflows harder to exploit because you can’t just stick shellcode bytes into your buffer overflow and jump the CPU to it, because the CPU knows that the heap is data, and won’t let it run.
And even though the CPU in the affected Broadcom Wi-Fi hardware is very stripped down (it’s an ARM Cortex R4), it nevertheless has an MPU, or Memory Protection Unit.
You can set up the Cortex R4 so that your available memory is divided into up to 12 regions, each with its own access control parameters.
You can therefore lock down code so it’s executable but not writable, which prevents it being modified unexpectedly; and you can lock down data such as the heap so it’s writable but not executable, which prevents shellcode running from it.
Biniamini discovered that the Broadcom firmware had neatly divided up the 4GB address space (not all the address space has to be populated with actual RAM or ROM) something like this:
Address range Access control options ----------------------- ------------------------------ 0x00000000 - 0x0FFFFFFF Readable, Writable, Executable 0x10000000 - 0x1FFFFFFF Readable, Writable, Executable 0x20000000 - 0x3FFFFFFF Readable, Writable, Executable 0x40000000 - 0x7FFFFFFF Readable, Writable, Executable 0x80000000 - 0xFFFFFFFF Readable, Writable, Executable
In other words, the firmware went to the trouble of configuring the MPU yet took no benefit from it: memory was split up into five areas open to everyone,.
(Apparently, newer Broadcom Wi-Fi firmware does use the MPU purposefully, meaning that this problem will die out as older devices get retired or updated.)
The third missed opportunity is ASLR, or address space layout randomisation, where both your code and its associated data end up in different memory addresses each time.
The Broadcom Wi-Fi SoC firmware isn’t stored on the chip itself; instead, the main computer installs a copy of the firmware every time the Wi-Fi chip is restarted, typically when the host device is itself turned off and back on.
By rearranging the firmware layout each time, even if only slightly, you make a much less predictable target for a would-be attacker.
For example, in Biniamini’s proof-of-concept code showing how to research and exploit this hole, he relies in numerous places on knowing where in memory certain code and data is going to be, with different hard-wired addresses needed for different firmware versions.
Making the firmware memory map different on every device by randomising it every time the device starts up means that an attacker can’t rely on known addresses.
Once again, ASLR doesn’t make remote code execution exploits impossible – if one part of the system accidentally give away the memory map currently in use, for example, and another part contains a potential remote code execution exploit hole, then the two vulnerabilities can be chained together to form a working exploit.
But ASLR combined with DEP makes the job much harder for the crooks.
Of course, to be fair to Broadcom, for all that the flaws are in Broadcom’s code, the buck doesn’t stop there.
After all, Google, Apple and others who chose to use the affected hardware and firmware in their own devices have to accept their share of responsibility.
This is especially true in the case of locked-down devices like iPhones where you can’t apply your own updates even if you want to: the buggy firmware is loaded from the host device’s own file system, so only the vendor can install the update for you.
What to do?
This RCE exploit can, in theory, be triggered by any other device connected to the same Wi-Fi network as you, but it doesn’t get right inside your device: the crooks are still only the periphery.
Nevertheless, we think it’s a problem to have exploitable Wi-Fi firmware, not least because that’s where all your Wi-Fi data gets shovelled in and out, which is why we recommended patching this bug on your iPhone as soon as possible.
What’s tricky in this case is being sure exactly which devices are at risk: recent iPhones have already been patched, and so have some Google Nexus and Pixel phones, but we can’t give you a list of other devices that might be affected.
The problem is that this particular bug and the current patches for it are more of an example and a symptom than a general fix.
We know that one particular Broadcom Wi-Fi SoC running one version of Broadcom’s proprietary firmware is definitely affected using one of the bugs that Biniamini found, because he published a proof-of-concept to demonstrate it.
But we also know that Biniamini found the “no DEP” problem on a Nexus 5, which didn’t receive a patch from Google; we can guess that the stripped-down heap management code might be in other widespread Broadcom firmware, too; and we can assume that Broadcom SoCs of the same era don’t make use of ASLR, either.
Worse still, Google says it has a second part to this story – a hack whereby an attacker can “pivot” from the Wi-Fi chip to run code on the host device itself – but the company hasn’t published that part yet.
In other words, this bug is potentially serious, but in real-life terms, it’s a bit futile to worry too much about it given the unknown number of combinations of hardware, firmware, host devices and operating systems that might be affected.
If you’re really worried:
- Stick to 3G/4G connections and turn Wi-Fi off while you are out and about.
- Power off and restart your device from time to time, which reloads the Wi-Fi firmware. (Biniamini’s exploit patches the firmware temporarily in memory, not persistently on the host device’s disk.)
- Ask your vendor or carrier for information, and grab any updates as soon as you can.