Posted yesteryear Gal Beniamini,
It’s a good understood fact that platform safety is an integral constituent of the safety of complex systems. For mobile devices, this declaration rings fifty-fifty truer; modern mobile platforms include multiple processing units, all elaborately communicating alongside ane another. While the code running on the application processor (AP) has been the dependent champaign of much research, other components have got seldom received the same scrutiny.
Over the years, equally a termination of the focused attending yesteryear safety folk, the defenses of code running on the application processor have got been reinforced. Taking Android equally a instance study, this includes hardening the operating system, improving the safety of applications, together with introducing incremental safety enhancements affecting the entire system. All positive improvements, no doubt. However, attackers tend to follow the path of to the lowest degree resistance. Improving the safety of ane element volition inevitably crusade some attackers to start looking elsewhere for an easier dot of entry.
In this two-part weblog series, we’ll explore the exposed assault surface introduced yesteryear Broadcom’s Wi-Fi SoC on mobile devices. Specifically, we’ll focus our attending on devices running Android, although a vast amount of this enquiry applies to other systems including the same Wi-Fi SoCs. The starting fourth dimension weblog post volition focus on exploring the Wi-Fi SoC itself; we’ll regain together with exploit vulnerabilities which volition allow us to remotely gain code execution on the chip. In the minute weblog post, we’ll farther elevate our privileges from the SoC into the the operating system’s kernel. Chaining the 2 together, we’ll demonstrate total device takeover yesteryear Wi-Fi proximity alone, requiring no user interaction.
We’ll focus on Broadcom’s Wi-Fi SoCs since they are the most mutual Wi-Fi chipset used on mobile devices. Influenza A virus subtype H5N1 partial listing of devices which brand utilisation of this platform includes the Nexus 5, half-dozen together with 6P, most Samsung flagship devices, together with all iPhones since the iPhone 4. For the purpose of this weblog post, we’ll demonstrate a Wi-Fi remote code execution exploit on a fully updated (at the time, now fixed) Nexus 6P, running Android 7.1.1 version NUF26K.
All the vulnerabilities inwards the post have got been disclosed to Broadcom. Broadcom has been incredibly responsive together with helpful, both inwards fixing the vulnerabilities together with making the fixes available to affected vendors. For a consummate timeline, meet the bug tracker entries. They’ve also been really opened upwards to discussions relating to the safety of the Wi-Fi SoC.
I would similar to give thank yous Thomas Dullien (@halvarflake) for helping kicking upwards the research, for the productive brainstorming, together with for helping search the literature for whatever relevant clues. I’d also similar to give thank yous my colleagues inwards the London business office for helping brand feel of the exploitation constraints, together with for listening to my ramblings.
Why-Fi?
In the yesteryear decade, the utilisation of Wi-Fi has give-up the ghost commonplace on mobile devices. Gradually, Wi-Fi has evolved into a formidable laid of specifications—some detailing the physical layer, others focusing on the MAC layer. In gild to bargain alongside this increased complexity, vendors have got started producing “FullMAC” Wi-Fi SoCs.
In essence, these are little SoCs that perform all the PHY, MAC together with MAC SubLayer Management Entity (MLME) processing on their own, allowing the operating arrangement to abstract itself away from the complex (and sometimes chip-specific) features related to Wi-Fi. The introduction of Wi-Fi FullMAC chips has also improved the powerfulness consumption of mobile devices, since much of the processing is done on a low-power SoC instead of the power-hungry application processor. Perhaps most importantly, FullMAC chips are much easier to integrate, equally they implement the MLME inside their firmware, reducing the complexity on the host’s side.
All that said together with done, the introduction of Wi-Fi FullMAC chips does non come upwards without a cost. Introducing these novel pieces of hardware, running proprietary together with complex code bases, may weaken the overall safety of the devices together with innovate vulnerabilities which could compromise the entire system.
Exploring the Platform
To start off our research, we’ll demand to regain some way to explore the Wi-Fi chip. Luckily, Cypress has latterly acquired Broadcom’s Wireless IOT business, together with have got published many of the datasheets related to Broadcom’s Wi-Fi chipsets (albeit for a slightly older SoC, the BCM4339). Reading through the datasheet, nosotros gain some insight into the hardware architecture behind the Wi-Fi chipset.
Specifically, nosotros tin meet that there’s an ARM Cortex R4 core, which runs all the logic for treatment together with processing frames. Moreover, the datasheet reveals that the ARM core has 640KB of ROM used to concur the firmware’s code, together with 768KB of RAM which is used for information processing (e.g., heap) together with to shop patches to firmware code.
To start analysing the code running on the ARM core, we’ll demand to extract the contents of the ROM, together with to locate the information that is loaded into RAM.
Let’s start yesteryear tackling the minute work starting fourth dimension - where is the information that’s loaded into the ARM core’s RAM? Since this information is non nowadays inwards ROM, it must live loaded externally when the chip starting fourth dimension powers on. Therefore, yesteryear reading through the initialisation code inwards the host’s driver, nosotros should live able to locate the file containing the RAM’s contents. Indeed, going over the driver’s code, nosotros regain the BCMDHD_FW_PATH config, which is used to announce the location of the file whose contents are uploaded to RAM yesteryear the driver.
So what virtually the ROM’s contents? One way to extract the ROM would live to utilisation the host driver’s chip retentiveness access capabilities (via PIO over SDIO or PCIe) to read the ROM’s contents directly. However, doing so would require modifying the driver to enable us to number the commands needed to dump the ROM. Another way to recollect the ROM would live to charge our ain modified firmware file into RAM, into which we’ll insert a little stub that tin live used to dump the ROM’s retentiveness range. Luckily, none of these approaches is genuinely needed inwards this case; Broadcom provides an extremely powerful command-line utility called dhdutil, which tin live used to interact alongside the chip via the bcmdhd driver.
Among the diverse capabilities this utility supports, it also allows us to straight read together with write retentiveness on the dongle yesteryear issuing a special command - “membytes”. Since nosotros already know the size of the ROM (from the datasheet), nosotros tin precisely utilisation the membytes command to read the ROM’s contents directly. However, there’s ane lastly inquiry nosotros demand to response starting fourth dimension - where is the ROM located? According to the great research done yesteryear the folks behind NexMon, the ROM is loaded at address 0x0, together with the RAM is loaded at address 0x180000 (while NexMon focused on BCM4339, this fact remains truthful for newer chips equally well, such equally the BCM4358).
Finally, putting all this together, nosotros tin acquire the RAM’s contents from the firmware file, dump the ROM using dhdutil, together with combine the 2 into a unmarried file which nosotros tin together with so start analysing inwards IDA.
Analysing the Firmware
Due to the relatively little size of the available retentiveness (both ROM together with RAM), Broadcom went to extreme efforts inwards gild to conserve memory. For starters, they’ve stripped the symbols together with most of the strings from the binary. This has the added bonus of making it slightly to a greater extent than cumbersome to reverse-engineer the firmware’s code. They’ve also opted for using the Thumb-2 educational activity laid exclusively, which allows for improve code density. As a result, the ROM picture on the BCM4358 is so tightly packed that it contains less than 300 unused bytes.
However, this is still non quite enough... Remember that the RAM has to accommodate the heap, stack together with global information structures, equally good equally all the patches or modifications to ROM functions. Quite a tall gild for a measly 768KB. To acquire unopen to this, Broadcom has decided to house all the functions that are only used during the firmware’s initialisation inwards 2 special regions. Once the initialisation is completed, these regions are “reclaimed”, together with are thereafter converted into heap chunks.
What’s more, heap chunks are interspersed betwixt code together with information structures inwards RAM - since the latter sometimes have got alignment requirements (or are referenced straight from ROM, so they cannot live moved). The terminate termination is that RAM is a jumbled mess of heap chunks, code together with information structures.
After spending some fourth dimension analysing the firmware, nosotros tin start identifying at to the lowest degree a few strings containing constituent names together with other hints, helping us acquire a grasp of the code base. Additionally, the NexMon researchers have got released their gathered symbols corresponding to firmware on the BCM4339. We tin apply the same symbols to the BCM4339’s firmware, together with and so utilisation bindiff to correlate the symbol names inwards newer firmware versions for to a greater extent than recent chips.
Lastly, there’s ane to a greater extent than fob inwards our lid - Broadcom produces SoftMAC chips inwards improver to the FullMAC SoCs we’re analysing. Since these SoftMAC chips don’t grip the MLME layer, their corresponding driver must perform that processing. As a result, much of Broadcom’s MLME processing code is included inwards the open-source SoftMAC driver - brcmsmac. While this won’t assist us out alongside whatever of the chip-specific features or the to a greater extent than internal processing code, it does seem to part many utility functions alongside the firmware’s code.
Hunting for Bugs
Now that nosotros have got a grasp of the firmware’s construction together with have got the way to analyse it, nosotros tin finally start hunting for bugs. But… Where should nosotros start?
Even alongside all the tricks mentioned before, this is a relatively large together with opaque binary, together with strings or symbols are few together with far between. One possibility would live to musical instrument the firmware inwards gild to line the code paths taken spell a package is received together with processed. The Cortex R4 does, indeed, have got debug registers which tin live used to house breakpoints together with inspect the code flow at diverse locations. Alternately, nosotros could manually locate a laid of functions which are used to parse together with recollect information from a received frame, together with piece of work our way backwards from there.
This is where familiarity alongside Wi-Fi comes inwards handy; Wi-Fi management frames encode most of their information inwards little “tagged” chunks of data, called Information Elements (IEs). These tagged chunks of information are structured equally TLVs, where the tag together with length fields are a unmarried byte long.
Since a large portion of the information transferred inwards Wi-Fi frames (other than the information itself) is encoded using IEs, they brand for adept candidates from which nosotros tin piece of work our way backwards. Moreover, equally “tag” values are unique together with standardised, nosotros tin utilisation their values to assist familiarise ourselves alongside the currently handled code flow.
Looking at the brcmsmac driver, nosotros tin meet that there’s a unmarried constituent which Broadcom uses inwards gild to extract IEs from a frame - bcm_parse_tlvs. After a brief search (by correlating hints from nearby strings), nosotros regain the same constituent inwards the firmware’s ROM. Great.
Now nosotros tin start cross-referencing locations which telephone telephone this function, together with opposite each of these call-sites. While substantially easier than reversing every constituent of the firmware, this still takes a considerable amount of fourth dimension (as the constituent has to a greater extent than than 110 cross-references, some to other wrapper functions which themselves are called from multiple locations).
After opposite applied scientific discipline all of the telephone telephone sites, I’ve found a few vulnerabilities related to the treatment of information elements embedded inwards management frames.
Two of the vulnerabilities tin live triggered when connecting to networks supporting wireless roaming features; 802.11r Fast BSS Transition (FT), or Cisco’s CCKM roaming. On the ane side, these vulnerabilities should live relatively straightforward to exploit - they are unproblematic stack overflows. Moreover, the operating arrangement running on the firmware (HNDRTE) does non utilisation stack cookies, so there’s no additional information leak or bypass required.
However, spell these vulnerabilities may live comfortable to exploit, they require some set-up to acquire working. First, we’d demand to broadcast Wi-Fi networks that back upwards these features. 802.11r FT is an open(-ish) standard, together with is implemented yesteryear hostapd. In contrast, CCKM is a proprietary measure (although some information tin live found online). Figuring out how to emulate a CCKM network (or buying a CCKM-capable WLC from Cisco) would live cumbersome (or costly).
Additionally, we’d demand to figure out which devices genuinely back upwards the aforementioned features. Broadcom provides many features which tin live licensed yesteryear customers -- non all features are nowadays on all devices (in fact, their corresponding patches likely wouldn’t fifty-fifty fit inwards RAM).
Luckily, Broadcom makes it tardily to distinguish which features are genuinely nowadays inwards each firmware image. The lastly few bytes inwards the RAM contents downloaded to the chip comprise the firmware’s “version string”. This string contains the engagement at which the firmware was compiled, the chip’s revision, the firmware’s version together with a listing of dash-delimited “tags”. Each tag represents a characteristic that is supported yesteryear the firmware image. For example, here’s the version string from the Nexus 6P:
4358a3-roml/pcie-ag-p2p-pno-aoe-pktfilter-keepalive-sr-mchan-pktctx-hostpp-lpc-pwropt-txbf-wl11u-mfp-betdls-amsdutx5g-txpwr-rcc-wepso-sarctrl-btcdyn-xorcsum-proxd-gscan-linkstat-ndoe-hs20sta-oobrev-hchk-logtrace-rmon-apf-d11status Version: 7.112.201.1 (r659325) CRC: 8c7aa795 Date: Tue 2016-09-13 15:05:58 PDT Ucode Ver: 963.317 FWID: 01-ba83502b
The presence of the 802.11r FT characteristic is indicated yesteryear the “fbt” tag. Similarly, back upwards for CCKM is indicated yesteryear the “ccx” tag. Unfortunately, it seems that the Nexus 6P supports neither of these features. In fact, running a quick search for the “ccx” characteristic (CCKM support) on my ain repository of Android firmware images revealed that this characteristic is non supported on whatever Nexus device, but is supported on a broad diversity of Samsung flagship devices, a really partial listing of which includes the Milky Way S7 (G930F, G930V), the Milky Way S7 Edge (G935F, G9350), the Milky Way S6 Edge (G925V) together with many more.
So what virtually the other 2 vulnerabilities? Both of them relate to the implementation of Tunneled Direct Link Setup (TDLS). TDLS connections allow peers on a Wi-Fi network to telephone commutation information betwixt ane some other without passing it through the Access Point (AP), thus preventing congestion at the AP.
Support for TDLS inwards the firmware is indicated yesteryear the “betdls” together with “tdls” tags. Searching through my firmware repository I tin meet that the vast bulk of devices do, indeed, back upwards TDLS. This includes all recent Nexus devices (Nexus 5, 6, 6P) together with most Samsung flagships.
What’s more, TDLS is specified equally constituent of the 802.11z standard (requires IEEE subscription). Since all the information regarding TDLS is available, nosotros could read the measure inwards gild to gain familiarity alongside the relevant code paths inwards Broadcom’s implementation. As an opened upwards standard, it is also supported yesteryear open-source supplicants, such equally wpa_supplicant. As a result, nosotros tin inspect the implementation of the TDLS features inwards wpa_supplicant inwards gild to farther improve our agreement of the relevant code inwards the firmware.
Lastly, equally we’ll meet later on, triggering these 2 vulnerabilities tin live done yesteryear whatever peer on the Wi-Fi network, without requiring whatever activity on the constituent of the device existence attacked (and alongside no indication that such an assault is taking place). This makes these vulnerabilities all the to a greater extent than interesting to explore.
In whatever case, it seems similar we’ve made our take heed up! We’re going to exploit the TDLS vulnerabilities. Before nosotros practise so, however, let’s have got a minute to larn a lilliputian fleck virtually TDLS, together with the vulnerabilities discovered (skip this constituent it you’re already familiar alongside TDLS).
802.11z TDLS 101
There are many utilisation cases where 2 peers on the same Wi-Fi network want to transfer large swaths of information betwixt ane another. For example, casting a video from your mobile device to your Chromecast would require large amounts of information to live transmitted. In most cases, the Chromecast would live relatively nearby to the caster (after all, you’d likely live watching the enshroud to which you’re casting). Therefore, it would seem wasteful to hit the entire information flow from the device to the AP, only to together with so hit it on to the Chromecast.
It’s non precisely the increased latency of adding an additional hop (the AP) that volition degrade the connection’s quality. Passing such large amounts of information to the AP would also position a strain on the AP itself, crusade congestion, together with would degrade the Wi-Fi connectivity for all peers on the network.
This is where TDLS comes into play. TDLS is meant to supply a way of peer-to-peer communication on a Wi-Fi network that is AP-independant.
Over The Air
Let’s start yesteryear familiarising ourselves alongside the construction of TDLS frames. As yous may know, 802.11 frames utilisation the “flags” champaign inwards gild to bespeak the “direction” inwards which a frame is travelling (from the client to the AP, AP to client, etc.). TDLS traffic co-opts the utilisation of the flag values indicating traffic inwards an Ad-Hoc (IBSS) network (To-DS=0, From-DS=0).
Next, TDLS frames are identified yesteryear a special ethertype value - 0x890D. TDLS frames transmitted over Wi-Fi utilisation a constant value inwards the “payload type” field, indicating that the payload has the next structure:
The category for TDLS frames is also laid to a constant value. This leaves us alongside only ane champaign which distinguishes betwixt dissimilar TDLS frame types - the “action code”. This 1-byte champaign indicates the kind of TDLS frame we’re transmitting. This, inwards turn, controls the way inwards which the “payload” inwards interpreted yesteryear the receiving end.
High-Level Flow
Before 2 peers tin found a connection, they must starting fourth dimension know virtually the existence of ane another. This is called the “discovery” phase. Influenza A virus subtype H5N1 Wi-Fi client that wishes to regain TDLS-capable peers on the network, tin practise so yesteryear sending a “TDLS Discovery Request” frame to a peer. Influenza A virus subtype H5N1 TDLS-capable peer that receives this frame, responds yesteryear sending a “TDLS Discovery Response” frame. The asking together with response are correlated to ane some other using a 1-byte “dialog token”.
Next, the peers may want to laid upwards a connection. To practise so, they must perform a 3-way handshake. This handshake serves a dual purpose; first, it indicates that a connexion is successfully established betwixt the 2 peers. Second, it’s used to derive the TDLS Peer Key (TPK), which secures the TDLS traffic betwixt the peers.
Finally, in ane lawsuit the connexion is created, the 2 peers tin telephone commutation peer traffic betwixt ane another. When ane of the peers wishes to tear-down the connection, they may practise so yesteryear sending a “TDLS Teardown” frame. Upon reception of such a frame, the TDLS-peer volition withdraw the connexion together with gratis upwards all the related resources.
Now that nosotros know plenty virtually TDLS, let’s have got a closer facial expression at the vulnerabilities at hand!
The Primitives
In gild to ensure the integrity of messages transferred during the setup together with teardown phases, the corresponding TDLS frames include Message Integrity Codes (MIC). For the setup phase, in ane lawsuit the minute handshake message (M2) is received, the TPK tin live derived yesteryear both parties. Using the TPK, the TDLS-initiator tin calculate a MIC over the contents of the 3rd handshake frame, which tin together with so live verified yesteryear the TDLS-responder.
The MIC is calculated over the contents of the IEs encoded inwards the handshake frame, equally follows:
So how tin nosotros regain these calculations inwards the firmware’s code? Well, equally luck would have got it, some strings referring to TDLS were left-over inwards the firmware’s ROM, allowing us to speedily dwelling theater inwards on the relevant functions.
After reverse-engineering much of the flow leading upwards to the processing of treatment TDLS activity frames, nosotros finally hit the constituent responsible for treatment TDLS Setup Confirm (PMK M3) frames. The constituent starting fourth dimension performs some validations to ensure that the asking is legitimate. It queries the internal information structures to ensure that a TDLS connexion is indeed existence laid upwards alongside the requesting peer. Then, it verifies the Link-ID IE (by checking that its encoded BSSID matches that of the electrical flow network), together with also verifies the 32-byte initiator nonce (“Snonce”) value (by comparison it to the stored initial nonce).
Once a sure as shooting grade of confidence is established that the asking may indeed live legitimate, the constituent moves on to telephone telephone an internal helper function, tasked alongside calculating the MIC together with ensuring that it matches the ane encoded inwards the frame. Quite helpfully, the firmware also includes the shout out for this constituent (“wlc_tdls_cal_mic_chk”).
After reverse-engineering the function, nosotros acquire inwards at the next guess high-level logic:
1. uint8_t* buffer = malloc(256);
2. uint8_t* pos = buffer;
3.
4. //Copying the initial (static) information
5. uint8_t* linkid_ie = bcm_parse_tlvs(..., 101);
6. memcpy(pos, linkid_ie + 0x8, 0x6); pos += 0x6; //Initiator MAC
7. memcpy(pos, linkid_ie + 0xE, 0x6); pos += 0x6; //Responder MAC
8. *pos = transaction_seq; pos++; //TransactionSeq
9. memcpy(pos, linkid_ie, 0x14); pos += 0x14; //LinkID-IE
10.
11. //Copying the RSN IE
12. uint8_t* rsn_ie = bcm_parse_tlvs(..., 48);
13. if (rsn_ie[1] + 2 + (pos - buffer) > 0xFF) {
14. ... //Handle overflow
15. }
16. memcpy(pos, rsn_ie, rsn_ie[1] + 2); pos += rsn_ie[1] + 2; //RSN-IE
17.
18. //Copying the remaining IEs
19. uint8_t* timeout_ie = bcm_parse_tlvs(..., 56);
20. uint8_t* ft_ie = bcm_parse_tlvs(..., 55);
21. memcpy(pos, timeout_ie, 0x7); pos += 0x7; //Timeout Interval IE
22. memcpy(pos, ft_ie, 0x54); pos += 0x54; //Fast-Transition IE
As tin live seen above, although the constituent verifies that the RSN IE’s length does non go yesteryear the allocated buffer’s length (line 13), it fails to verify that the subsequent IEs also practise non overflow the buffer. As such, setting the RSN IE’s length to a large value (e.g., such that rsn_ie[1] + 2 + (pos - buffer) == 0xFF) volition crusade the Timeout Interval together with Fast Transition IEs to live copied out-of-bounds, inundation the buffer.
For example, assuming nosotros laid the length of the RSN IE (x) to its maximal possible value, 224, nosotros acquire inwards at the next placements of elements:
In this diagram, orangish fields are those which are “irrelevant” for the overflow, since they are positioned inside the buffer’s bounds. Red fields bespeak values that cannot live fully controlled yesteryear us, together with dark-green fields bespeak values which are fully controllable.
For example, the Timeout Interval IE is verified prior to the MIC’s calculation together with only has a constrained laid of allowed values, making it uncontrollable. Similarly, the FTIE’s tag together with length fields are constant, together with thus non controllable. Lastly, the 32-byte “Anonce” value is randomly chosen yesteryear the TDLS responder, placing it firmly out of our champaign of influence.
But the province of affairs isn’t that grim. In fact, several of the fields inwards the FTIE itself tin live arbitrarily chosen - for example, the “Snonce” value is chosen yesteryear the TLDS-initiator during the starting fourth dimension message inwards the handshake. Moreover, the “MIC Control” champaign inwards the FTIE tin live freely chosen, since it is non verified prior to the execution of this function.
In whatever case, at nowadays that we’ve audited the MIC verification for the setup stage, let’s plow our sights towards the MIC verification during the teardown stage. Perhaps the code is similarly broken there? Taking a facial expression at the MIC calculation inwards the teardown stage (“wlc_tdls_cal_mic_chk”), nosotros acquire inwards at the next high-level logic:
1. uint8_t* buffer = malloc(256);
2. ...
3. uint8_t* linkid_ie = bcm_parse_tlvs(..., 101); //Link ID
4. memcpy(buffer, linkid_ie, 0x14);
5. ...
6. uint8_t* ft_ie = bcm_parse_tlvs(..., 55);
7. memcpy(buffer + 0x18, ft_ie, ft_ie[1] + 2); //Fast-Transition IE
Ah-ha, so in ane lawsuit once to a greater extent than a straightforward overflow; the FT-IE’s length champaign is non verified to ensure that it doesn’t go yesteryear the length of the allocated buffer. This way that only yesteryear providing a crafted FT-IE, nosotros tin trigger the overflow. Nevertheless, in ane lawsuit once to a greater extent than at that spot are several verifications prior to triggering the vulnerable code path which bound our command on the inundation elements. Let’s seek together with plot the placement of elements during the overflow:
This seems much simpler - nosotros don’t demand to worry ourselves virtually the values stored inwards the FTIE that are verified prior to the overflow, since they’re all placed neatly inside the buffer’s range. Instead, the assailant controlled portion is only spare information that is non dependent champaign to whatever verification, together with tin thus live freely chosen yesteryear us. That said, the overflow’s extent is quite express - nosotros tin only overwrite at most 25 bytes beyond the hit of the buffer.
Writing an Exploit
Investigating the Heap State
At long lastly nosotros have got a grasp of the primitives at hand. Now, it’s fourth dimension to seek out whether our hypotheses check reality. To practise so, we’ll demand a testbed that’ll enable us to shipping crafted frames, triggering the overflows. Recall that wpa_supplicant is an open-source portable supplicant that fully supports TDLS. This makes it a prime number candidate for our enquiry platform. We could utilisation wpa_supplicant equally a base of operations on top of which we’ll arts and crafts our frames. That would relieve us the demand to re-implement all the logic entailed inwards setting upwards together with maintaining a TDLS connection.
To seek out the vulnerabilities, we’ll modify wpa_supplicant to allow us to shipping TDLS Teardown frames containing an overly-large FTIE. Going over wpa_supplicant’s code, nosotros tin speedily seat the constituent inwards accuse of generating together with sending the teardown frame - wpa_tdls_send_teardown. By adding a few little changes to this constituent (in green) nosotros should live able to trigger the overflow upon reception the teardown frame, causing 25 bytes of 0xAB to live written OOB:
static int wpa_tdls_send_teardown(struct wpa_sm *sm, const u8 *addr, u16 reason_code)
{
...
ftie = (struct wpa_tdls_ftie *) pos;
ftie->ie_type = WLAN_EID_FAST_BSS_TRANSITION;
ftie->ie_len = 255;
os_memset(pos + 2, 0x00, ftie->ie_len);
os_memset(pos + ftie->ie_len + 2 - 0x19, 0xAB, 0x19); //Overflowing alongside 0xAB
os_memcpy(ftie->Anonce, peer->rnonce, WPA_NONCE_LEN);
os_memcpy(ftie->Snonce, peer->inonce, WPA_NONCE_LEN);
pos += ftie->ie_len + 2;
...
}
Now nosotros precisely demand to interact alongside wpa_supplicant inwards gild to setup together with teardown a TDLS connexion to our target device. Conveniently, wpa_supplicant supports many command interfaces, including a command-line utility called wpa_cli. This command line interface also supports several commands exposing TDLS functionality:
- TDLS_DISCOVER - Sends a “TDLS Discovery Request” frame together with lists the response
- TDLS_SETUP - Creates a TDLS connexion to the peer alongside the given MAC address
- TDLS_TEARDOWN - Tears downwards the TDLS connexion to the peer alongside the given MAC
Indeed, after compiling wpa_supplicant alongside TDLS back upwards (CONFIG_TDLS), setting upwards a network, together with connecting our target device together with our enquiry platform to the network, nosotros tin meet that issuing the TDLS_DISCOVER command industrial plant - nosotros tin indeed seat our peer.
Moving on, nosotros tin at nowadays shipping a TDLS_SETUP command, followed yesteryear our crafted TDLS_TEARDOWN. If everything adds upwards correctly, this should trigger the overflow. However, this raises a slightly to a greater extent than subtle inquiry - how volition nosotros know when the overflow occurs? It may precisely so hit off that the information we’re inundation is unused. Alternately, it may live the instance that when the firmware crashes, it precisely silently starts upwards again, leaving us none the wiser.
To response this fully, we’ll demand to empathise the logic behind Broadcom’s heap implementation. Digging into the allocator’s logic, nosotros regain that it is extremely straightforward; it is a unproblematic “best-fit” allocator, which performs forrard together with backward coalescing, together with keeps a singly linked listing of gratis chunks. When chunks are allocated, they are carved from the terminate (highest address) of the best-fitting gratis chunk (smallest chunk that is large enough). Heap chunks have got the next structure:
(recall that the Cortex R4 is a 32-bit ARM processor, so all fields are stored inwards little-endian)
By reverse-engineering the allocator’s implementation, nosotros tin also regain the location of the pointer to the caput of the starting fourth dimension free-chunk inwards RAM. Combining these 2 facts together, nosotros tin create a utility which, given a dump of the firmware’s RAM, tin plot the electrical flow nation of the heap’s freelist. Acquiring a snapshot of the firmware’s RAM tin live easily achieved yesteryear using dhdutil’s “upload” command.
After writing a little visualiser script which walks over the heap’s freelist together with exports the its contents into dot, nosotros tin plot the nation of the freelist using graphviz, similar so:
Now, nosotros tin shipping out crafted TDLS_TEARDOWN frame, instantly have got a snapshot of the firmware’s RAM, together with cheque the freelist for whatever signs of corruption:
Ah-ha! Indeed ane of the chunks inwards the freelist of a abrupt has an exceptionally large size after violent downwards the connection. Recall that since the allocator uses “best-fit”, this way that subsequent allocations won’t live placed inwards this block equally long equally other large plenty gratis chunks exist. This also way that the firmware did non crash, together with inwards fact continued to constituent correctly. Had nosotros non visualised the nation of the heap, nosotros wouldn’t have got been able to determine anything had happened at all.
In whatever case, at nowadays that we’ve confirmed that the overflow does inwards fact occur, it’s fourth dimension to motion to the next stage of exploitation. We demand less unsmooth tools inwards gild to allow us to monitor the nation of the heap during the setup together with teardown processes. To this end, it would live advantageous to claw the malloc together with gratis functions inwards the firmware, together with to line their arguments together with render values.
First, we’ll demand to write a “patcher”, which volition allow us to insert hooks on given RAM-resident functions. It’s of import to authorities notation that both the malloc together with free functions are both nowadays inwards RAM (they are amid the starting fourth dimension functions inwards the RAM’s code chunk). This allows us to freely re-write their prologues inwards gild to innovate a branch to our ain code. I’ve written a patcher which performs insertion of such hooks, allowing execution of little assembly stubs before together with after the invocation of the hooked function.
In short, the patcher is fairly measure - it writes the patch’s code to an unused part inwards RAM (the caput of the largest gratis chunk inwards the heap), together with and so inserts a Thumb-2 broad branch (which is, coincidentally, perhaps the ugliest encoding for an opcode I’ve always seen - meet 4.6.12 T4) from the prologue of the hooked constituent to the claw itself.
Using our novel patcher, nosotros tin at nowadays musical instrument the malloc together with free functions inwards gild to add together traces allowing us to follow every functioning occurring on the heap. These traces tin together with so live read from the firmware’s console buffer, yesteryear issuing dhdutil’s “consoledump” command. Note that on some newer chips, similar the BCM4358 on the Nexus 6P, this command fails. This is because Broadcom forgot to add together the offset to the magic pointer inwards the firmware pointing to the console’s information structure. You tin gear upwards this either yesteryear adding the right offset to the driver (see debug_info_ptrs), or yesteryear writing the magic value together with pointer to ane of the probed retentiveness addresses inwards the list.
In whatever case, yous tin regain both the malloc together with gratis hooks, together with the associated scripts needed to parse the traces from the firmware, here.
Using the newly acquired traces, nosotros tin write a improve visualiser, allowing us to line the nation of the heap throughout the setup together with teardown phases. This visualiser volition have got visibility into every functioning occurring on the heap, offering far to a greater extent than granular data. I’ve written such a visualiser, which yous tin regain here.
Without farther ado, let’s have got a facial expression at heap activity spell establishing a TDLS connection:
The vertical axis denotes fourth dimension - each line is a novel heap nation after a malloc or free operation. The horizontal axis denotes infinite - lower addresses are on the left, spell higher addresses are on the right. Red blocks bespeak chunks that are in-use, grayness blocks bespeak gratis chunks.
As nosotros tin clearly meet above, establishing a TDLS connexion is a messy operation. There are many allocations together with deallocations, for regions both large together with small. This abundance of vibrations doesn’t bode good for us. Recall that the overflow during the setup stage is highly constrained, both inwards price of the information existence written, together with inwards price of the extent of the inundation data. Moreover, the overflow occurs during ane of the many allocations inwards the setup phase. This doesn’t allow us much command over the nation of the heap prior to triggering the overflow.
Taking a mensuration back, however, nosotros tin detect a fairly surprising fact. Apart from the heap activity during the TDLS connexion establishment, it seems similar at that spot is lilliputian to no activity on the heap whatsoever. In fact, it turns out that transmitted together with received frames are drawn from a shared pool, instead of the heap. Not only that, but their processing doesn’t incur a single heap functioning - everything is done “in-place”. Even when trying to intentionally crusade allocations yesteryear sending random frames containing exotic fleck combinations, the firmware’s heap remains largely unaffected.
This is both a approving together with a curse. On the ane hand, it way that the heap’s construction is highly consistent. In the seldom events that information structures are allocated, they are instantly freed thereafter, restoring the heap to its original state. On the other hand, it way that our grade of control over the heap’s construction is fairly limited. For the most part, whatever construction the heap has after the firmware’s initialisation, is what we’re going to have got to piece of work alongside (unless, of course, nosotros regain some primitive that volition allow us to improve shape the heap).
Perhaps nosotros should have got a facial expression at the teardown stage instead? Indeed, activating the traces during the TDLS teardown stage reveals that at that spot are really few allocations prior to triggering the overflow, so it seems similar a much to a greater extent than convenient surroundings to explore.
While these in-depth traces are useful for getting a high-level thought of the heap’s state, they are rather hard to decipher. In fact, inwards most cases it’s sufficient to have got a unmarried snapshot of the heap together with precisely visualise it, equally nosotros did before alongside the graphviz visualiser. In that case, let’s improve our previous heap visualiser yesteryear allowing it to make detailed graphical output, based on a unmarried snapshot of the heap.
As we’ve seen earlier, nosotros tin “walk” over the freelist to extract the location together with size of each gratis chunk. Moreover, nosotros tin deduce the location of in-use chunks yesteryear walking over the gaps between gratis chunks together with reading the “size” champaign from each in-use chunk. I’ve written yet some other visualiser that does precisely that - it only produces a visualisation of the heap’s nation from a serial of “snapshot” images.
Using this visualiser, nosotros tin at nowadays have got a facial expression at the nation of the heap after setting upwards a TDLS connection. This volition live the nation of the heap nosotros demand to piece of work alongside when nosotros trigger the overflow during the teardown stage.
(Upper Layer: initial heap state, Bottom Layer: heap nation after creating a TDLS connection)
We tin meet that after setting upwards the TDLS connection, most of the heap’s used chunks are consecutive, but also 2 holes are formed; ane of size 0x11C, together with some other of size 0x124. Activating the traces for the teardown stage, nosotros tin meet that the next allocations occur:
(29) malloc - size: 284, caller: 1828bb, res: 1f0404
(30) gratis - ptr: 1f0404
(31) malloc - size: 20, caller: 18c811, res: 1f1654
(32) malloc - size: 160, caller: 18c811, res: 1f0480
(33) malloc - size: 8, caller: 80eb, res: 1f2a44
(34) gratis - ptr: 1f2a44
(35) gratis - ptr: 1f1654
(36) gratis - ptr: 1f0480
(37) malloc - size: 256, caller: 7aa15, res: 1f0420
(38) malloc - size: 16, caller: 7aa23, res: 1f1658
The highlighted line denotes the allotment of the 256-byte buffer for the teardown frame’s MIC calculation, that same ane nosotros tin overflow using our vulnerability. Moreover, it seems equally though the heap activity is quite depression prior to sending the overflow frame. Combining the heap snapshot higher upwards alongside the line file, nosotros tin deduce that the best-fitting chunk for the 256-byte buffer is inwards the 0x11C-byte hole. This way that using our 25-byte overflow we’ll live able to overwrite:
- The header of the next in-use chunk
- A few bytes from the contents of the next in-use chunk
Let’s have got a closer facial expression at the next in-use chunk together with meet whether there’s whatever interesting information that we’d similar to overwrite there:
Ah, so the next chunk is to a greater extent than oft than non empty, relieve for a pair of pointers close its head. Are these pointers of whatever utilisation to us? Perhaps they are written to? Or freed at a later stage? We tin regain out yesteryear manually corrupting these pointers (pointing them at invalid retentiveness addresses, such equally 0xCDCDCDCD), together with instrumenting the firmware’s exception vector to meet whether it crashes. Unfortunately, after many such attempts, it seems equally though none of these pointers are inwards fact used.
This leaves us, therefore, alongside a unmarried possibility - corrupting the “size” champaign of the in-use chunk. Recall that in ane lawsuit the TDLS connexion is torn down, the information structures relating to it are freed. Freeing an in-use chunk whose size we’ve corrupted could have got many interesting consequences. For starters, if nosotros cut down the size of the chunk, nosotros tin intentionally “leak” the tail terminate of the buffer, causing it to stay forever un-allocatable. Much to a greater extent than interestingly, however, nosotros could laid the chunk’s size to a larger value, thereby causing the next gratis functioning to create a gratis chunk whose tail terminate overlaps some other heap chunk.
Once a gratis chunk overlaps some other heap chunk, subsequent allocations for which the overlapping gratis chunk is the best-fit volition live carved from the terminate of the gratis chunk, thereby corrupting whatever fields reside at its tail. Before nosotros start scheming, however, nosotros demand to confirm that nosotros tin create such a nation (i.e., an overlapping chunk), after the teardown functioning completes.
Creating an Overlapping Chunk
Recall that the MIC cheque is precisely ane of many operations that have got house when a TDLS connexion is torn down. It may precisely so hit off that yesteryear overwriting the next chunk’s size, in ane lawsuit it is freed during the collection of the TDLS session’s information structures, it may give-up the ghost the best-fit for subsequent allocations during the teardown process. These allocations may together with so crusade additional unintended corruptions, which volition either leave of absence the heap inwards a non-consistent nation or fifty-fifty crash the firmware.
However, the search infinite for possible sizes isn’t that large - assuming we’re only interested inwards chunk sizes that are non larger than the RAM itself (for obvious reasons), nosotros tin only enumerate each of the heap states produced yesteryear overwriting the “size” champaign of the next chunk alongside a given value together with violent downwards the connection. This tin live automated yesteryear using a script on the sending (to perform the enumeration), spell concurrently acquiring “snapshots” of RAM on the device, together with observing their nation (whether or non they are consistent, together with whether the firmware managed to resume functioning after the teardown).
Specifically, it would live highly advantageous if nosotros were able to create a heap nation whereby 2 gratis chunks overlap ane another. In such a condition, allocations taken from ane chunk, tin live used to corrupt the “next” pointer of the other gratis chunk. This could live used, perhaps, to command the location of subsequent allocations - an interesting primitive inwards it’s ain right.
In whatever case, after running through a few chunk sizes, violent downwards the TDLS connexion together with observing the heap state, nosotros come upwards across quite an interesting resulting state! By overwriting the “size” champaign alongside the value 72 together with violent downwards the connection, nosotros accomplish the next heap state:
Great! So after violent downwards the connection, nosotros are left alongside a zero-sized gratis chunk, overlapping a dissimilar (larger) gratis chunk! This way that in ane lawsuit an allotment is carved from the large chunk, it volition corrupt the “size” together with “next” fields of the smaller chunk. This could evidence really useful - nosotros could seek together with dot the next gratis chunk at a retentiveness address whose contents we’d similar to modify. As long equally the information inwards that address conforms alongside the format of a gratis chunk, nosotros mightiness live able to persuade the heap to overwrite the retentiveness at that address alongside subsequent allocations.
Finding a Controlled Allocation
To start exploring these possibilities, we’ll starting fourth dimension demand to create a controlled allotment primitive, meaning nosotros either command the size of the allocation, or it’s contents, or (ideally) both. Recall that, equally we’ve seen previously, it is inwards fact really hard to trigger allocations during the normal processing of the firmware - nearly all the processing is done in-place. Moreover, fifty-fifty for cases where information is allocated, its lifespan is really short; retentiveness is instantly reclaimed in ane lawsuit it’s no longer used.
Be that equally it may, we’ve already seen at to the lowest degree ane laid of information structures whose lifetime is controllable, together with which contains multiple dissimilar pieces of information - the TDLS connexion itself. The firmware must maintain all the information pertaining to the TDLS connexion equally long equally its active. Perhaps nosotros could regain some information construction relating to TDLS which could human activity equally a adept candidate for a controlled allocation?
To search for one, let’s start yesteryear looking at the constituent treatment each of the TDLS activity frames - wlc_tdls_rcv_action_frame. The constituent starts yesteryear reading out the TDLS category together with activity code. Then, it routes the frame to the appropriate handler function, according to the received activity code:
We tin meet that apart from the regular, specification-defined activity codes, the firmware also supports an out-of-spec frame alongside an activity code of 127. Anything out-of-spec is automatically suspect, so that mightiness live equally adept a house equally whatever to facial expression for our primitive.
Indeed, excavation into this function, nosotros regain out that it performs a rather curious task. First, it verifies that the starting fourth dimension iii bytes inwards the frame’s contents check the Wi-Fi alliance OUI (50:6F:9A). Then, it retrieves the 4th byte of the frame, together with uses it equally a “command code”. Currently, only 2 vendor-specific commands are implemented, commands #4 together with #5. On a high-level; command #4 is used to shipping a tunneled probe asking over the TDLS connection, together with command #5 is used to shipping an “event” notification to the host, signalling that a “special” frame has arrived.
However, much to a greater extent than interestingly, nosotros meet that the implementation for command #4 seems relevant to our electrical flow pursuit. First, it does non require the existence of a TDLS connexion inwards gild to live processed! This allows us to shipping the frame fifty-fifty after violent downwards the connection. Second, yesteryear activating heap traces during this function’s execution together with reverse-engineering its logic, nosotros regain that the constituent triggers the next high-level sequence of events:
1. if (A) { free(A); }
2. A = malloc(received_frame_size);
3. memcpy(A, received_frame, received_frame_size);
4. B = malloc(788);
5. free(B)
6. C = malloc(284);
7. free(C);
Great! So nosotros acquire an allotment (A) alongside a controlled lifetime, a controlled size together with controlled contents! What to a greater extent than could nosotros maybe inquire for?
There is ane tiny snag, however. Modifying wpa_supplicant to shipping this crafted TDLS frame results inwards a resounding failure. While wpa_supplicant allows us to fully command many of the fields inwards the TDLS frames, it is only a supplicant, non an MLME implementation. This way that the corresponding MLME layer is responsible for composing together with sending the actual TDLS frames.
On the setup I’m using for the assault platform, I have got a laptop running Ubuntu 16.04, together with a TP-Link TL-WN722N dongle. The dongle is a SoftMAC configuration, so the MLME layer inwards play is the ane nowadays inwards the Linux kernel, namely, the “cfg80211” configuration layer.
When wpa_supplicant wishes to create together with shipping TDLS frames, it does so yesteryear sending special requests over Netlink, which are together with so handled yesteryear the cfg80211 framework, together with after passed to the SoftMAC layer, “mac80211”. Regrettably, however, mac80211 is unable to procedure the special vendor frames, together with only rejects them. Nonetheless, this is precisely a little inconvenience - I’ve written a few patches to mac80211 which add together back upwards for these special vendor frames. After applying these patches, re-compiling together with booting the kernel, nosotros are at nowadays able to shipping our crafted frames.
To allow for easier command over the vendor frames, I’ve also added back upwards for a novel command inside wpa_supplicant’s CLI - “TDLS_VNDR”. This command allows us to shipping a crafted TDLS vendor frame alongside arbitrary information to whatever MAC address (regardless of whether a TDLS connexion is established to that peer).
Putting It All Together
After creating 2 overlapping chunks, nosotros tin at nowadays utilisation our controlled allotment primitive to allocate retentiveness from the tail of the larger chunk, thereby pointing the smaller gratis chunk at a location of our choosing. Whichever location nosotros choose, however, must have got valid values for both the “size” together with “next” fields, otherwise later calls to malloc together with free may fail, maybe crashing the firmware. As a thing of fact, we’ve already seen perfect candidates to stand-in for gratis chunks - in-use chunks!
Recall that in-use chunks specify their size champaign at the same location gratis chunks practise theirs. As for the “next” pointer, it is unused inwards gratis chunks, but is set to zero during the allotment of the chunk. This way that yesteryear corrupting the gratis listing to dot at an in-use chunk, nosotros tin fob the heap into thinking it’s precisely some other gratis chunk, which is coincidentally also the lastly chunk inwards the freelist. That’s comfortable.
Now all nosotros demand to practise is regain an in-use chunk containing information that we’d similar to overwrite. If nosotros brand that chunk the best-fitting chunk inwards the gratis listing for a subsequent controlled allocation, we’ll acquire our ain information to live allocated at that spot instead of the in-use chunk’s data, effectively replacing the chunk’s contents. This way we’re able to arbitrarily supplant the contents of whatever in-use chunk.
As we’re interested inwards achieving total code execution, it would live advantageous to locate together with overwrite a constituent pointer inwards the heap. But… Where tin nosotros await to regain such values on the heap? Well, for starters, at that spot are some events inwards the Wi-Fi standards that must live handled periodically, such equally performing scans for next networks. It would likely live a prophylactic bet to assume that the firmware supports treatment such periodic timers yesteryear using a mutual API.
Since timers may live created during the firmware’s operation, their information structures (e.g., which constituent to execute together with when) must live stored on the heap. To locate these timers, nosotros tin reverse-engineer the IRQ vector tabular array entry, together with search for the logic corresponding to treatment a timer interrupt. After doing so, nosotros regain a linked listing of entries whose contents seem to conform to that of brcms_timer structure, used inwards the brcmsmac (SoftMAC) driver. After writing a brusk script, nosotros tin dump the listing of timers given a RAM snapshot:
We tin meet that the timer listing is ordered yesteryear the timeout value, together with most of the timers have got a relatively brusk timeout. Moreover, all the timers are allocated during the firmware’s initialisation, together with are thus stored at constant addresses. This is of import since, if we’d similar to target our gratis chunk at a timer, we’d demand to know it’s exact location inwards memory.
So all that’s left is to utilisation our 2 primitives to supplant the contents of ane of the timers higher upwards alongside our ain data, consequently pointing the timer’s constituent at an address of our choosing.
Here’s the game plan. First, we’ll utilisation the techniques described higher upwards to create 2 overlapping gratis chunks. Now, nosotros tin utilisation the controlled allotment primitive to dot the smaller gratis chunk at ane of the timers inwards the listing above. Next, nosotros create some other controlled allotment (freeing the former one). This ane volition live of size 0x3C, for which the timer chunk is the best-fitting. Therefore, at this point, we’ll overwrite the timer’s contents.
But which constituent practise nosotros dot our timer to? Well, nosotros tin utilisation the same fob to commandeer some other in-use chunk on the heap, together with overwrite its contents alongside our ain shellcode. After briefly searching the heap, nosotros come upwards across a large chunk which only contains console information during the chip’s kicking sequence, together with is together with so left allocated but unused. Not only is the allotment is fairly large (0x400 bytes), but it is also placed at a constant address (since it is allocated during the firmware’s initialisation sequence) - perfect for our exploit.
Lastly, how tin nosotros live sure as shooting that the contents of the heap is fifty-fifty executable? After all, the ARM Cortex R4 has a Memory Protection Unit (MPU). Unlike an MMU, it does non allow for the facilitation of a virtual address space, but it does allow command over the access permissions of dissimilar retentiveness ranges inwards RAM. Using the MPU, the heap could (and should) live marked equally RW together with non-executable.
By reversing the firmware’s initialisation routines inwards the binary, nosotros tin meet that the MPU is indeed existence activated during boot. But what are the contents alongside which it’s configured? We tin regain out yesteryear writing a little assembly stub to dump out the contents of the MPU:
0x00000000 - 0x10000000
AP: iii - Full access
XN: 0
0x10000000 - 0x20000000
AP: iii - Full access
XN: 0
0x20000000 - 0x40000000
AP: iii - Full access
XN: 0
0x40000000 - 0x80000000
AP: iii - Full access
XN: 0
0x80000000 - 0x100000000
AP: iii - Full access
XN: 0
Ah-ha - spell the MPU is initialised, it is effectively laid to grade all of retentiveness equally RWX, making it useless. This saves us some hassle… We tin conveniently execute our code straight from the heap.
So, at long last, nosotros have got an exploit ready! Putting it all together nosotros tin at nowadays hijack a code chunk to shop our shellcode, together with so hijack a timer to dot it at our stored shellcode. Once the timer expires, our code volition live executed on the firmware!
At long last, we’ve gone through the entire procedure of researching the platform, discovering a vulnerability together with writing a full-fledged exploit. Although this post is relatively long, at that spot are many smaller details that I left out inwards favour of brevity. If yous have got whatever specific questions, delight allow me know. You tin regain the total exploit, including instructions, here. The exploit includes a relatively benign shellcode, which only writes a magic value to address 0x200000 inwards the firmware’s RAM, signalling successful execution.
Wrapping Up
We’ve seen that spell the firmware implementation on the Wi-Fi SoC is incredibly complex, it still lags behind inwards price of security. Specifically, it lacks all basic exploit mitigations - including stack cookies, prophylactic unlinking together with access permission protection (by way of an MPU).
Broadcom have got informed me that newer versions of the SoC utilise the MPU, along alongside several additional hardware safety mechanisms. This is an interesting evolution together with a mensuration inwards the right direction. They are also considering implementing exploit mitigations inwards futurity firmware versions.
In the next weblog post, we’ll meet how nosotros tin utilisation our assumed command of the Wi-Fi SoC inwards gild to farther escalate our privileges into the application processor, taking over the host’s operating system!
Komentar
Posting Komentar