Do you have an iPhone? Did it suddenly update IoS at the end of last week? That's because of a vulnerability discovered by a researcher, Nitay Arenstein, in the Broadcom Wi-Fi chip. Since lots of phones, not just iPhone, use this same chip, the vulnerability extends to a lot of Android phones too. I assume they have been patched by Google, but Android is fragmented and so it will depend on the manufacturer as to when any particular phone gets fixed. In China, many "Android" phones run a forked version of the code that has little to do with Google and so may remain vulnerable. For anyone involved in SoC design, this should be a wakeup call. IP blocks and secondary chips in devices may be vulnerable to security flaws. It is not just the highly visible x86 processor in a PC or server, or the highly visible ARM processor in a smartphone. Those other processors are not using what Microsoft, Apple and Android have learned the hard way. They will have to start doing so. DEP and ASLR Malware on computers, such as viruses and worms that propagate from one system to another, have become a lot more difficult. The typical way that these worked was through buffer overflow problems where data was not properly checked before being written into the buffer. Typically, instead of writing a few bytes or a few hundred bytes, the exploit would write a huge amount, maybe even a megabyte. That would overwrite the code of the application in a very predictable way. Most of the code would be left unchanged but some critical part of the code would be altered in a way that gave the attacker control. The reason that this has got a lot more difficult in the last decade is due to two techniques: DEP (Data Execution Prevention) ASLR (Address Space Layout Randomization) In the distant past, memory was divided up into 3 classes: no access, read access and write access. No distinction used to be made as to why the code was being read, and if a memory area was writable, it was certainly readable (and so it could be run as code too, which is only read access). If a bad guy somehow managed to get a buffer full of code on the stack and then persuade the program to execute it, then it was comparatively easy to gain control. DEP adds another layer of protection, by marking some areas as not containing executable code. This is orthogonal to the other protection. As I just said, the stack is writable, but it does not contain code and so should not be executable. By doing this, it makes it considerably more difficult to insert some malicious code and persuade the application to execute it. This requires hardware support, in the form of an NX (no execute) bit. This is actually called XD (execute disable) by Intel, and XN (execute never) by ARM. Of course, it also requires operating system support to correctly set the bits so that areas that contain just data, especially the heap and the stack, are marked with this bit in the memory tables. This was first implemented on PCs in 2004 in a service pack upgrade to Microsoft Windows XP. If an attempt is made to execute code from an area marked with the NX bit, a hardware exception is generated and the operating system gets control to clean up, just as if an illegal instruction was executed. You get a dialog similar to the one above. The other technique, ASLR, means that when the various pieces of code and data are loaded into memory, instead of being in a fixed and predictable configuration they are loaded at random addresses. This makes it much harder to exploit a buffer overflow (or similar) issue since it is no longer clear what extra data needs to make up the overflow. The code that is to be overwritten will be in a different place each time the code is loaded. It is no longer possible to overflow the buffer in a way that duplicates a lot of code and replaces a few key instructions since what is required will vary each time, with no way to find out just how. The result of this has been that it is much more difficult to attack a system remotely. If you have access to the device, there might be things that you can exploit (by, for example, loading a new App), but that clearly doesn't scale in a scary way. Similarly, there are exploits that work by requiring the user to visit a website or click on a link in an email ("phishing"). BROADPWN The reason BROADPWN is so scary is that it is the first remote exploit for a long time that doesn't require anything special, just to be nearby. The victim phone just needs to be in Wi-Fi range. Once a phone is infected, it can potentially be a vector to infect any other phones within Wi-Fi range. Just as with something like the common cold virus, which can spread rapidly from person to person, it can spread phone to phone without any further interaction. An exploit that can propagate like this used to be called a worm, but that name hasn't been around for ages because there haven't been any new worms...until now. The name BROADPWN comes from Broadcom (the manufacturer of the Wi-Fi chip used in most smartphones) and PWN which means "own" in the sense of completely taking over something. It originally was a typo in a game, like the bizarre "all your bases are belong to us". The researchers got control of the Wi-Fi chip. However, they never went the final few steps of using that control to take over the host application processor, never mind use that to compromise other devices in range. However, they had already done the heavy lifting and the remaining steps were regarded as straightforward. Building the Malware In order to build this exploit, there needs to be a bug such as a buffer overflow in the Wi-Fi chip. The chip runs an obscure proprietary operating system, but it has been used for other things and the source code is available on the net even though it is not officially open source (probably it is not meant to be on the net, but it is). Nitay found a potential buffer overflow, a copy of one object to another, without checking that the destination is large enough: In a classic bug, the program calls memcpy() in the last line without verifying that the buffer current_wmm_ie (our name) is large enough to hold the data of size ie->len. But it’s too early to call it a bug. As we can see in the last section, the current_wmm_ie buffer is allocated with a length of 0x2c (44) bytes, while the maximum size for an IE is 0xff (255) bytes. This means that we have a nice maximum overflow of 211 bytes. The actual exploit is too complex to detail here. If you are interested there is a lot of detail in Nitay's document (link at the end of the post). It goes through several steps, getting a little primitive created, getting that up to full code execution, then (in theory) getting across from the Broadcom Wi-Fi chip to gain control of the application processor. He lists three ways to do this, but only implemented the simplest and least powerful. However, there is no reason to assume that the other methods won't work, although one will only work on newer phones that use PCIe. Other Exploits Now that this has been done and made public, there will probably be other vulnerabilities discovered in other SoCs. Until now, DEP and ASLR have not been used on the firmware inside SoCs like the Broadcom Wi-Fi chip. But as Nitay Artenstein says: Old school hackers often miss the “good old days” of the early 2000s, when remotely exploitable bugs were abundant, no mitigations were in place to stop them, and worms and malware ran rampant. But with new research opening previously unknown attack surface such as the BCM Wi-Fi chip, those times may just be making a comeback. One conclusion from all this is that SoCs cannot ignore malware issues, and perhaps should take advantage of the experience built up over the decades in PCs and the application processor chips in smartphones, which are the most exposed and vulnerable to external attack. But Wi-Fi chips, Bluetooth chips, USB blocks/chips, and other chips can potentially be attacked, especially if they have their own interfaces to the outside world (which all the radio chips like Wi-Fi and Bluetooth do by definition). Details For full details (very technical) on the exploit, see Nitay's exposition BROADPWN: Remotely Compromising Android and iOS Via a Bug in Broadcom's Wi-Fi Chipsets , or for a less technical exposition, see Wired's How a Bug in an Obscure Chip Exposed a Billion Smartphones to Hackers . He also presented his results at the recent Black Hat security conference. Sign up for Sunday Brunch, the weekly Breakfast Bytes email.![]()
![]()
↧