Posted past times Gal Beniamini,
It’s a good understood fact that platform security is an integral portion of the security of complex systems. For mobile devices, this declaration rings fifty-fifty truer; modern mobile platforms include multiple processing units, all elaborately communicating amongst 1 another. While the code running on the application processor (AP) has been the dependent plain of much research, other components have got seldom received the same scrutiny.
Over the years, every bit a outcome of the focused attending past times security folk, the defenses of code running on the application processor have got been reinforced. Taking Android every bit a instance study, this includes hardening the operating system, improving the security of applications, as well as introducing incremental security 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 security of 1 ingredient volition inevitably elbow grease 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 past times 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 kickoff weblog postal service volition focus on exploring the Wi-Fi SoC itself; we’ll regain as well as 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 past times 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 exercise of this platform includes the Nexus 5, six as well as 6P, most Samsung flagship devices, as well as 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 inward the postal service have got been disclosed to Broadcom. Broadcom has been incredibly responsive as well as helpful, both inward fixing the vulnerabilities as well as making the fixes available to affected vendors. For a consummate timeline, run into the bug tracker entries. They’ve also been real opened upwards to discussions relating to the security of the Wi-Fi SoC.
I would similar to give thank y'all Thomas Dullien (@halvarflake) for helping boot upwards the research, for the productive brainstorming, as well as for helping search the literature for whatever relevant clues. I’d also similar to give thank y'all my colleagues inward the London business office for helping brand feel of the exploitation constraints, as well as for listening to my ramblings.
Why-Fi?
In the past times decade, the exercise of Wi-Fi has acquire 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 fellowship to bargain amongst this increased complexity, vendors have got started producing “FullMAC” Wi-Fi SoCs.
In essence, these are little SoCs that perform all the PHY, MAC as well as 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, every bit they implement the MLME inside their firmware, reducing the complexity on the host’s side.
All that said as well as done, the introduction of Wi-Fi FullMAC chips does non come upwards without a cost. Introducing these novel pieces of hardware, running proprietary as well as complex code bases, may weaken the overall security of the devices as well as 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 lately acquired Broadcom’s Wireless IOT business, as well as 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 run into that there’s an ARM Cortex R4 core, which runs all the logic for treatment as well as processing frames. Moreover, the datasheet reveals that the ARM core has 640KB of ROM used to concur the firmware’s code, as well as 768KB of RAM which is used for information processing (e.g., heap) as well as 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, as well as to locate the information that is loaded into RAM.
Let’s start past times tackling the minute work kickoff - where is the information that’s loaded into the ARM core’s RAM? Since this information is non nowadays inward ROM, it must live loaded externally when the chip kickoff powers on. Therefore, past times reading through the initialisation code inward 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 past times the driver.
So what most the ROM’s contents? One way to extract the ROM would live to exercise 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 remember 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 inward this case; Broadcom provides an extremely powerful command-line utility called dhdutil, which tin live used to interact amongst the chip via the bcmdhd driver.
Among the diverse capabilities this utility supports, it also allows us to straight read as well as write retentiveness on the dongle past times issuing a special command - “membytes”. Since nosotros already know the size of the ROM (from the datasheet), nosotros tin exactly exercise the membytes command to read the ROM’s contents directly. However, there’s 1 lastly query nosotros demand to response kickoff - where is the ROM located? According to the great research done past times the folks behind NexMon, the ROM is loaded at address 0x0, as well as the RAM is loaded at address 0x180000 (while NexMon focused on BCM4339, this fact remains truthful for newer chips every bit well, such every bit the BCM4358).
Finally, putting all this together, nosotros tin acquire the RAM’s contents from the firmware file, dump the ROM using dhdutil, as well as combine the 2 into a unmarried file which nosotros tin so start analysing inward IDA.
Analysing the Firmware
Due to the relatively little size of the available retentiveness (both ROM as well as RAM), Broadcom went to extreme efforts inward fellowship to conserve memory. For starters, they’ve stripped the symbols as well as 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 education 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 as well as global information structures, every bit good every bit all the patches or modifications to ROM functions. Quite a tall fellowship for a measly 768KB. To acquire around this, Broadcom has decided to house all the functions that are only used during the firmware’s initialisation inward 2 special regions. Once the initialisation is completed, these regions are “reclaimed”, as well as are thereafter converted into heap chunks.
What’s more, heap chunks are interspersed betwixt code as well as information structures inward RAM - since the latter sometimes have got alignment requirements (or are referenced straight from ROM, so they cannot live moved). The terminate outcome is that RAM is a jumbled mess of heap chunks, code as well as information structures.
After spending some fourth dimension analysing the firmware, nosotros tin start identifying at to the lowest degree a few strings containing role names as well as 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, as well as so exercise bindiff to correlate the symbol names inward newer firmware versions for to a greater extent than recent chips.
Lastly, there’s 1 to a greater extent than draw a fast 1 on inward our chapeau - Broadcom produces SoftMAC chips inward improver to the FullMAC SoCs we’re analysing. Since these SoftMAC chips don’t take hold the MLME layer, their corresponding driver must perform that processing. As a result, much of Broadcom’s MLME processing code is included inward the open-source SoftMAC driver - brcmsmac. While this won’t aid us out amongst whatever of the chip-specific features or the to a greater extent than internal processing code, it does seem to part many utility functions amongst the firmware’s code.
Hunting for Bugs
Now that nosotros have got a grasp of the firmware’s construction as well as have got the way to analyse it, nosotros tin finally start hunting for bugs. But… Where should nosotros start?
Even amongst all the tricks mentioned before, this is a relatively large as well as opaque binary, as well as strings or symbols are few as well as far between. One possibility would live to musical instrument the firmware inward fellowship to describe the code paths taken patch a bundle is received as well as processed. The Cortex R4 does, indeed, have got debug registers which tin live used to house breakpoints as well as inspect the code flow at diverse locations. Alternately, nosotros could manually locate a laid of functions which are used to parse as well as remember information from a received frame, as well as piece of work our way backwards from there.
This is where familiarity amongst Wi-Fi comes inward handy; Wi-Fi administration frames encode most of their information inward little “tagged” chunks of data, called Information Elements (IEs). These tagged chunks of information are structured every bit TLVs, where the tag as well as length fields are a unmarried byte long.
Since a large portion of the information transferred inward Wi-Fi frames (other than the information itself) is encoded using IEs, they brand for proficient candidates from which nosotros tin piece of work our way backwards. Moreover, every bit “tag” values are unique as well as standardised, nosotros tin exercise their values to aid familiarise ourselves amongst the currently handled code flow.
Looking at the brcmsmac driver, nosotros tin run into that there’s a unmarried role which Broadcom uses inward fellowship to extract IEs from a frame - bcm_parse_tlvs. After a brief search (by correlating hints from nearby strings), nosotros regain the same role inward the firmware’s ROM. Great.
Now nosotros tin start cross-referencing locations which telephone yell upwards this function, as well as opposite each of these call-sites. While substantially easier than reversing every portion of the firmware, this still takes a considerable amount of fourth dimension (as the role 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 yell upwards sites, I’ve found a few vulnerabilities related to the treatment of information elements embedded inward administration 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 1 side, these vulnerabilities should live relatively straightforward to exploit - they are uncomplicated stack overflows. Moreover, the operating arrangement running on the firmware (HNDRTE) does non exercise stack cookies, so there’s no additional information leak or bypass required.
However, patch 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, as well as is implemented past times 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 past times customers -- non all features are nowadays on all devices (in fact, their corresponding patches likely wouldn’t fifty-fifty fit inward RAM).
Luckily, Broadcom makes it tardily to distinguish which features are genuinely nowadays inward each firmware image. The lastly few bytes inward the RAM contents downloaded to the chip comprise the firmware’s “version string”. This string contains the appointment at which the firmware was compiled, the chip’s revision, the firmware’s version as well as a listing of dash-delimited “tags”. Each tag represents a characteristic that is supported past times 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 past times the “fbt” tag. Similarly, back upwards for CCKM is indicated past times 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 multifariousness of Samsung flagship devices, a real partial listing of which includes the Milky Way S7 (G930F, G930V), the Milky Way S7 Edge (G935F, G9350), the Milky Way S6 Edge (G925V) as well as many more.
So what most 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 substitution information betwixt 1 some other without passing it through the Access Point (AP), thus preventing congestion at the AP.
Support for TDLS inward the firmware is indicated past times the “betdls” as well as “tdls” tags. Searching through my firmware repository I tin run into that the vast bulk of devices do, indeed, back upwards TDLS. This includes all recent Nexus devices (Nexus 5, 6, 6P) as well as most Samsung flagships.
What’s more, TDLS is specified every bit portion of the 802.11z standard (requires IEEE subscription). Since all the information regarding TDLS is available, nosotros could read the measure inward fellowship to gain familiarity amongst the relevant code paths inward Broadcom’s implementation. As an opened upwards standard, it is also supported past times open-source supplicants, such every bit wpa_supplicant. As a result, nosotros tin inspect the implementation of the TDLS features inward wpa_supplicant inward fellowship to farther improve our agreement of the relevant code inward the firmware.
Lastly, every bit we’ll run into later on, triggering these 2 vulnerabilities tin live done past times whatever peer on the Wi-Fi network, without requiring whatever activeness on the portion of the device beingness attacked (and amongst 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 hear up! We’re going to exploit the TDLS vulnerabilities. Before nosotros practise so, however, let’s have got a minute to acquire a piffling combat most TDLS, as well as the vulnerabilities discovered (skip this portion it you’re already familiar amongst TDLS).
802.11z TDLS 101
There are many exercise cases where 2 peers on the same Wi-Fi network want to transfer large swaths of information betwixt 1 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 covert to which you’re casting). Therefore, it would seem wasteful to make the entire information flow from the device to the AP, only to so make it on to the Chromecast.
It’s non exactly 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 seat a strain on the AP itself, elbow grease congestion, as well as 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 past times familiarising ourselves amongst the construction of TDLS frames. As y'all may know, 802.11 frames exercise the “flags” plain inward fellowship to betoken the “direction” inward which a frame is travelling (from the client to the AP, AP to client, etc.). TDLS traffic co-opts the exercise of the flag values indicating traffic inward an Ad-Hoc (IBSS) network (To-DS=0, From-DS=0).
Next, TDLS frames are identified past times a special ethertype value - 0x890D. TDLS frames transmitted over Wi-Fi exercise a constant value inward 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 amongst only 1 plain which distinguishes betwixt unlike TDLS frame types - the “action code”. This 1-byte plain indicates the kind of TDLS frame we’re transmitting. This, inward turn, controls the way inward which the “payload” inward interpreted past times the receiving end.
High-Level Flow
Before 2 peers tin flora a connection, they must kickoff know most the existence of 1 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 past times sending a “TDLS Discovery Request” frame to a peer. Influenza A virus subtype H5N1 TDLS-capable peer that receives this frame, responds past times sending a “TDLS Discovery Response” frame. The asking as well as response are correlated to 1 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, 1 time the connexion is created, the 2 peers tin telephone substitution peer traffic betwixt 1 another. When 1 of the peers wishes to tear-down the connection, they may practise so past times sending a “TDLS Teardown” frame. Upon reception of such a frame, the TDLS-peer volition take away the connexion as well as gratis upwards all the related resources.
Now that nosotros know plenty most TDLS, let’s have got a closer expression at the vulnerabilities at hand!
The Primitives
In fellowship to ensure the integrity of messages transferred during the setup as well as teardown phases, the corresponding TDLS frames include Message Integrity Codes (MIC). For the setup phase, 1 time the minute handshake message (M2) is received, the TPK tin live derived past times both parties. Using the TPK, the TDLS-initiator tin calculate a MIC over the contents of the 3rd handshake frame, which tin so live verified past times the TDLS-responder.
The MIC is calculated over the contents of the IEs encoded inward the handshake frame, every bit follows:
So how tin nosotros regain these calculations inward the firmware’s code? Well, every bit luck would have got it, some strings referring to TDLS were left-over inward the firmware’s ROM, allowing us to speedily abode inward on the relevant functions.
After reverse-engineering much of the flow leading upwards to the processing of treatment TDLS activeness frames, nosotros finally make the role responsible for treatment TDLS Setup Confirm (PMK M3) frames. The role kickoff performs some validations to ensure that the asking is legitimate. It queries the internal information structures to ensure that a TDLS connexion is indeed beingness laid upwards amongst the requesting peer. Then, it verifies the Link-ID IE (by checking that its encoded BSSID matches that of the electrical flow network), as well as also verifies the 32-byte initiator nonce (“Snonce”) value (by comparison it to the stored initial nonce).
Once a surely grade of confidence is established that the asking may indeed live legitimate, the role moves on to telephone yell upwards an internal helper function, tasked amongst calculating the MIC as well as ensuring that it matches the 1 encoded inward the frame. Quite helpfully, the firmware also includes the cry for this role (“wlc_tdls_cal_mic_chk”).
After reverse-engineering the function, nosotros go far at the next estimate 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 role verifies that the RSN IE’s length does non overstep 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 elbow grease the Timeout Interval as well as Fast Transition IEs to live copied out-of-bounds, alluvion the buffer.
For example, assuming nosotros laid the length of the RSN IE (x) to its maximal possible value, 224, nosotros go far 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 betoken values that cannot live fully controlled past times us, as well as dark-green fields betoken values which are fully controllable.
For example, the Timeout Interval IE is verified prior to the MIC’s calculation as well as only has a constrained laid of allowed values, making it uncontrollable. Similarly, the FTIE’s tag as well as length fields are constant, as well as thence non controllable. Lastly, the 32-byte “Anonce” value is randomly chosen past times the TDLS responder, placing it firmly out of our plain of influence.
But the province of affairs isn’t that grim. In fact, several of the fields inward the FTIE itself tin live arbitrarily chosen - for example, the “Snonce” value is chosen past times the TLDS-initiator during the kickoff message inward the handshake. Moreover, the “MIC Control” plain inward 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 plough our sights towards the MIC verification during the teardown stage. Perhaps the code is similarly broken there? Taking a expression at the MIC calculation inward the teardown stage (“wlc_tdls_cal_mic_chk”), nosotros go far 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 1 time once to a greater extent than a straightforward overflow; the FT-IE’s length plain is non verified to ensure that it doesn’t overstep the length of the allocated buffer. This way that only past times providing a crafted FT-IE, nosotros tin trigger the overflow. Nevertheless, 1 time once to a greater extent than at that topographic point are several verifications prior to triggering the vulnerable code path which boundary our command on the alluvion elements. Let’s seek as well as plot the placement of elements during the overflow:
This seems much simpler - nosotros don’t demand to worry ourselves most the values stored inward 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 plain to whatever verification, as well as tin thence live freely chosen past times us. That said, the overflow’s extent is quite express - nosotros tin only overwrite at most 25 bytes beyond the make 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 out whether our hypotheses jibe reality. To practise so, we’ll demand a testbed that’ll enable us to ship 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 exercise wpa_supplicant every bit 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 inward setting upwards as well as maintaining a TDLS connection.
To seek out out the vulnerabilities, we’ll modify wpa_supplicant to allow us to ship TDLS Teardown frames containing an overly-large FTIE. Going over wpa_supplicant’s code, nosotros tin speedily seat the role inward accuse of generating as well as sending the teardown frame - wpa_tdls_send_teardown. By adding a few little changes to this role (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 amongst 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 exactly demand to interact amongst wpa_supplicant inward fellowship to setup as well as 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 as well as lists the response
- TDLS_SETUP - Creates a TDLS connexion to the peer amongst the given MAC address
- TDLS_TEARDOWN - Tears downward the TDLS connexion to the peer amongst the given MAC
Indeed, after compiling wpa_supplicant amongst TDLS back upwards (CONFIG_TDLS), setting upwards a network, as well as connecting our target device as well as our enquiry platform to the network, nosotros tin run into that issuing the TDLS_DISCOVER command industrial plant - nosotros tin indeed seat our peer.
Moving on, nosotros tin at nowadays ship a TDLS_SETUP command, followed past times 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 query - how volition nosotros know when the overflow occurs? It may exactly so spill out that the information we’re alluvion is unused. Alternately, it may live the instance that when the firmware crashes, it exactly silently starts upwards again, leaving us none the wiser.
To response this fully, we’ll demand to empathize the logic behind Broadcom’s heap implementation. Digging into the allocator’s logic, nosotros regain that it is extremely straightforward; it is a uncomplicated “best-fit” allocator, which performs forwards as well as backward coalescing, as well as 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 inward little-endian)
By reverse-engineering the allocator’s implementation, nosotros tin also regain the location of the pointer to the caput of the kickoff free-chunk inward 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 past times using dhdutil’s “upload” command.
After writing a little visualiser script which walks over the heap’s freelist as well as exports the its contents into dot, nosotros tin plot the nation of the freelist using graphviz, similar so:
Now, nosotros tin ship out crafted TDLS_TEARDOWN frame, forthwith have got a snapshot of the firmware’s RAM, as well as cheque the freelist for whatever signs of corruption:
Ah-ha! Indeed 1 of the chunks inward the freelist all of a abrupt has an exceptionally large size after violent downward the connection. Recall that since the allocator uses “best-fit”, this way that subsequent allocations won’t live placed inward this block every bit long every bit other large plenty gratis chunks exist. This also way that the firmware did non crash, as well as inward fact continued to role 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 inward fact occur, it’s fourth dimension to motion to the next stage of exploitation. We demand less unsmooth tools inward fellowship to allow us to monitor the nation of the heap during the setup as well as teardown processes. To this end, it would live advantageous to claw the malloc as well as gratis functions inward the firmware, as well as to describe their arguments as well as 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 banknote that both the malloc as well as free functions are both nowadays inward RAM (they are amidst the kickoff functions inward the RAM’s code chunk). This allows us to freely re-write their prologues inward fellowship 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 as well as after the invocation of the hooked function.
In short, the patcher is fairly measure - it writes the patch’s code to an unused part inward RAM (the caput of the largest gratis chunk inward the heap), as well as so inserts a Thumb-2 broad branch (which is, coincidentally, perhaps the ugliest encoding for an opcode I’ve e'er seen - run into 4.6.12 T4) from the prologue of the hooked role to the claw itself.
Using our novel patcher, nosotros tin at nowadays musical instrument the malloc as well as free functions inward fellowship to add together traces allowing us to follow every functioning occurring on the heap. These traces tin so live read from the firmware’s console buffer, past times 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 inward the firmware pointing to the console’s information structure. You tin laid upwards this either past times adding the right offset to the driver (see debug_info_ptrs), or past times writing the magic value as well as pointer to 1 of the probed retentiveness addresses inward the list.
In whatever case, y'all tin regain both the malloc as well as gratis hooks, as well as 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 describe the nation of the heap throughout the setup as well as 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 y'all tin regain here.
Without farther ado, let’s have got a expression at heap activity patch 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, patch higher addresses are on the right. Red blocks betoken chunks that are in-use, grayness blocks betoken gratis chunks.
As nosotros tin clearly run into above, establishing a TDLS connexion is a messy operation. There are many allocations as well as deallocations, for regions both large as well as small. This abundance of noise doesn’t bode good for us. Recall that the overflow during the setup stage is highly constrained, both inward damage of the information beingness written, as well as inward damage of the extent of the alluvion data. Moreover, the overflow occurs during 1 of the many allocations inward the setup phase. This doesn’t allow us much command over the nation of the heap prior to triggering the overflow.
Taking a measurement back, however, nosotros tin detect a fairly surprising fact. Apart from the heap activity during the TDLS connexion establishment, it seems similar at that topographic point is piffling to no activity on the heap whatsoever. In fact, it turns out that transmitted as well as 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 elbow grease allocations past times sending random frames containing exotic combat combinations, the firmware’s heap remains largely unaffected.
This is both a approbation as well as a curse. On the 1 hand, it way that the heap’s construction is highly consistent. In the seldom events that information structures are allocated, they are forthwith 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 amongst (unless, of course, nosotros regain some primitive that volition allow us to improve shape the heap).
Perhaps nosotros should have got a expression at the teardown stage instead? Indeed, activating the traces during the TDLS teardown stage reveals that at that topographic point are real few allocations prior to triggering the overflow, so it seems similar a much to a greater extent than convenient environs to explore.
While these in-depth traces are useful for getting a high-level stance of the heap’s state, they are rather hard to decipher. In fact, inward most cases it’s sufficient to have got a unmarried snapshot of the heap as well as exactly visualise it, every bit nosotros did before amongst the graphviz visualiser. In that case, let’s improve our previous heap visualiser past times 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 as well as size of each gratis chunk. Moreover, nosotros tin deduce the location of in-use chunks past times walking over the gaps between gratis chunks as well as reading the “size” plain from each in-use chunk. I’ve written yet some other visualiser that does exactly 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 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 amongst 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 run into that after setting upwards the TDLS connection, most of the heap’s used chunks are consecutive, but also 2 holes are formed; 1 of size 0x11C, as well as some other of size 0x124. Activating the traces for the teardown stage, nosotros tin run into 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 1 nosotros tin overflow using our vulnerability. Moreover, it seems every bit though the heap activity is quite depression prior to sending the overflow frame. Combining the heap snapshot inward a higher house amongst the describe file, nosotros tin deduce that the best-fitting chunk for the 256-byte buffer is inward 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 expression at the next in-use chunk as well as run into whether there’s whatever interesting information that we’d similar to overwrite there:
Ah, so the next chunk is generally empty, relieve for a distich of pointers nigh its head. Are these pointers of whatever exercise to us? Perhaps they are written to? Or freed at a later stage? We tin regain out past times manually corrupting these pointers (pointing them at invalid retentiveness addresses, such every bit 0xCDCDCDCD), as well as instrumenting the firmware’s exception vector to run into whether it crashes. Unfortunately, after many such attempts, it seems every bit though none of these pointers are inward fact used.
This leaves us, therefore, amongst a unmarried possibility - corrupting the “size” plain of the in-use chunk. Recall that 1 time 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 exactly 1 of many operations that have got house when a TDLS connexion is torn down. It may exactly so spill out that past times overwriting the next chunk’s size, 1 time it is freed during the collection of the TDLS session’s information structures, it may acquire the best-fit for subsequent allocations during the teardown process. These allocations may so elbow grease additional unintended corruptions, which volition either leave of absence the heap inward 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 inward chunk sizes that are non larger than the RAM itself (for obvious reasons), nosotros tin only enumerate each of the heap states produced past times overwriting the “size” plain of the next chunk amongst a given value as well as violent downward the connection. This tin live automated past times using a script on the sending (to perform the enumeration), patch concurrently acquiring “snapshots” of RAM on the device, as well as observing their nation (whether or non they are consistent, as well as 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 1 another. In such a condition, allocations taken from 1 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 inward it’s ain right.
In whatever case, after running through a few chunk sizes, violent downward the TDLS connexion as well as observing the heap state, nosotros come upwards across quite an interesting resulting state! By overwriting the “size” plain amongst the value 72 as well as violent downward the connection, nosotros accomplish the next heap state:
Great! So after violent downward the connection, nosotros are left amongst a zero-sized gratis chunk, overlapping a unlike (larger) gratis chunk! This way that 1 time an allotment is carved from the large chunk, it volition corrupt the “size” as well as “next” fields of the smaller chunk. This could bear witness real useful - nosotros could seek as well as dot the next gratis chunk at a retentiveness address whose contents we’d similar to modify. As long every bit the information inward that address conforms amongst the format of a gratis chunk, nosotros mightiness live able to persuade the heap to overwrite the retentiveness at that address amongst subsequent allocations.
Finding a Controlled Allocation
To start exploring these possibilities, we’ll kickoff 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, every bit we’ve seen previously, it is inward fact real 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 real short; retentiveness is forthwith reclaimed 1 time it’s no longer used.
Be that every bit it may, we’ve already seen at to the lowest degree 1 laid of information structures whose lifetime is controllable, as well as which contains multiple unlike pieces of information - the TDLS connexion itself. The firmware must maintain all the information pertaining to the TDLS connexion every bit long every bit its active. Perhaps nosotros could regain some information construction relating to TDLS which could deed every bit a proficient candidate for a controlled allocation?
To search for one, let’s start past times looking at the role treatment each of the TDLS activeness frames - wlc_tdls_rcv_action_frame. The role starts past times reading out the TDLS category as well as activeness code. Then, it routes the frame to the appropriate handler function, according to the received activeness code:
We tin run into that apart from the regular, specification-defined activeness codes, the firmware also supports an out-of-spec frame amongst an activeness code of 127. Anything out-of-spec is automatically suspect, so that mightiness live every bit proficient a house every bit whatever to expression for our primitive.
Indeed, earthworks into this function, nosotros regain out that it performs a rather curious task. First, it verifies that the kickoff iii bytes inward the frame’s contents jibe the Wi-Fi alliance OUI (50:6F:9A). Then, it retrieves the quaternary byte of the frame, as well as uses it every bit a “command code”. Currently, only 2 vendor-specific commands are implemented, commands #4 as well as #5. On a high-level; command #4 is used to ship a tunneled probe asking over the TDLS connection, as well as command #5 is used to ship an “event” notification to the host, signalling that a “special” frame has arrived.
However, much to a greater extent than interestingly, nosotros run into that the implementation for command #4 seems relevant to our electrical flow pursuit. First, it does non require the existence of a TDLS connexion inward fellowship to live processed! This allows us to ship the frame fifty-fifty after violent downward the connection. Second, past times activating heap traces during this function’s execution as well as reverse-engineering its logic, nosotros regain that the role 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) amongst a controlled lifetime, a controlled size as well as controlled contents! What to a greater extent than could nosotros maybe inquire for?
There is 1 tiny snag, however. Modifying wpa_supplicant to ship this crafted TDLS frame results inward a resounding failure. While wpa_supplicant allows us to fully command many of the fields inward the TDLS frames, it is only a supplicant, non an MLME implementation. This way that the corresponding MLME layer is responsible for composing as well as sending the actual TDLS frames.
On the setup I’m using for the assault platform, I have got a laptop running Ubuntu 16.04, as well as a TP-Link TL-WN722N dongle. The dongle is a SoftMAC configuration, so the MLME layer inward play is the 1 nowadays inward the Linux kernel, namely, the “cfg80211” configuration layer.
When wpa_supplicant wishes to create as well as ship TDLS frames, it does so past times sending special requests over Netlink, which are so handled past times the cfg80211 framework, as well as afterward passed to the SoftMAC layer, “mac80211”. Regrettably, however, mac80211 is unable to procedure the special vendor frames, as well as only rejects them. Nonetheless, this is exactly a small-scale 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 as well as booting the kernel, nosotros are at nowadays able to ship 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 ship a crafted TDLS vendor frame amongst 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 exercise 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” as well as “next” fields, otherwise later calls to malloc as well as free may fail, maybe crashing the firmware. As a affair 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 plain at the same location gratis chunks practise theirs. As for the “next” pointer, it is unused inward gratis chunks, but is set to zero during the allotment of the chunk. This way that past times corrupting the gratis listing to dot at an in-use chunk, nosotros tin draw a fast 1 on the heap into thinking it’s exactly some other gratis chunk, which is coincidentally also the lastly chunk inward 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 inward the gratis listing for a subsequent controlled allocation, we’ll acquire our ain information to live allocated at that topographic point instead of the in-use chunk’s data, effectively replacing the chunk’s contents. This way we’re able to arbitrarily supervene upon the contents of whatever in-use chunk.
As we’re interested inward achieving total code execution, it would live advantageous to locate as well as overwrite a role pointer inward the heap. But… Where tin nosotros await to regain such values on the heap? Well, for starters, at that topographic point are some events inward the Wi-Fi standards that must live handled periodically, such every bit performing scans for side past times side networks. It would likely live a security bet to assume that the firmware supports treatment such periodic timers past times using a mutual API.
Since timers may live created during the firmware’s operation, their information structures (e.g., which role to execute as well as when) must live stored on the heap. To locate these timers, nosotros tin reverse-engineer the IRQ vector tabular array entry, as well as 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 inward the brcmsmac (SoftMAC) driver. After writing a curt script, nosotros tin dump the listing of timers given a RAM snapshot:
We tin run into that the timer listing is ordered past times the timeout value, as well as most of the timers have got a relatively curt timeout. Moreover, all the timers are allocated during the firmware’s initialisation, as well as are thence 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 inward memory.
So all that’s left is to exercise our 2 primitives to supervene upon the contents of 1 of the timers inward a higher house amongst our ain data, consequently pointing the timer’s role at an address of our choosing.
Here’s the game plan. First, we’ll exercise the techniques described inward a higher house to create 2 overlapping gratis chunks. Now, nosotros tin exercise the controlled allotment primitive to dot the smaller gratis chunk at 1 of the timers inward the listing above. Next, nosotros create some other controlled allotment (freeing the onetime one). This 1 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 role practise nosotros dot our timer to? Well, nosotros tin exercise the same draw a fast 1 on to commandeer some other in-use chunk on the heap, as well as overwrite its contents amongst our ain shellcode. After briefly searching the heap, nosotros come upwards across a large chunk which only contains console information during the chip’s boot sequence, as well as is 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 surely 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 unlike retentiveness ranges inward RAM. Using the MPU, the heap could (and should) live marked every bit RW as well as non-executable.
By reversing the firmware’s initialisation routines inward the binary, nosotros tin run into that the MPU is indeed beingness activated during boot. But what are the contents amongst which it’s configured? We tin regain out past times 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 - patch the MPU is initialised, it is effectively laid to grade all of retentiveness every bit 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, 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 as well as writing a full-fledged exploit. Although this postal service is relatively long, at that topographic point are many smaller details that I left out inward favour of brevity. If y'all 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 inward the firmware’s RAM, signalling successful execution.
Wrapping Up
We’ve seen that patch the firmware implementation on the Wi-Fi SoC is incredibly complex, it still lags behind inward damage of security. Specifically, it lacks all basic exploit mitigations - including stack cookies, security unlinking as well as access permission protection (by way of an MPU).
Broadcom have got informed me that newer versions of the SoC utilise the MPU, along amongst several additional hardware security mechanisms. This is an interesting evolution as well as a measurement inward the right direction. They are also considering implementing exploit mitigations inward time to come firmware versions.
In the next weblog post, we’ll run into how nosotros tin exercise our assumed command of the Wi-Fi SoC inward fellowship to farther escalate our privileges into the application processor, taking over the host’s operating system!
Komentar
Posting Komentar