Vulnerabilities > CVE-2017-0561 - Out-of-bounds Write vulnerability in Linux Kernel 3.10/3.18
Attack vector
NETWORK Attack complexity
LOW Privileges required
NONE Confidentiality impact
COMPLETE Integrity impact
COMPLETE Availability impact
COMPLETE Summary
A remote code execution vulnerability in the Broadcom Wi-Fi firmware could enable a remote attacker to execute arbitrary code within the context of the Wi-Fi SoC. This issue is rated as Critical due to the possibility of remote code execution in the context of the Wi-Fi SoC. Product: Android. Versions: Kernel-3.10, Kernel-3.18. Android ID: A-34199105. References: B-RB#110814.
Vulnerable Configurations
| Part | Description | Count |
|---|---|---|
| OS | 2 |
Common Weakness Enumeration (CWE)
Exploit-Db
description Broadcom Wi-Fi SoC - TDLS Teardown Request Remote Heap Overflow Exploit. CVE-2017-0561. Remote exploit for Hardware platform file exploits/hardware/remote/41805.txt id EDB-ID:41805 last seen 2017-04-04 modified 2017-04-04 platform hardware port published 2017-04-04 reporter Exploit-DB source https://www.exploit-db.com/download/41805/ title Broadcom Wi-Fi SoC - TDLS Teardown Request Remote Heap Overflow Exploit type remote description Broadcom Wi-Fi SoC - Heap Overflow in "wlc_tdls_cal_mic_chk" Due to Large RSN IE in TDLS Setup Confirm Frame. CVE-2017-0561. Dos exploit for Hardwa... file exploits/hardware/dos/41806.txt id EDB-ID:41806 last seen 2017-04-04 modified 2017-04-04 platform hardware port published 2017-04-04 reporter Exploit-DB source https://www.exploit-db.com/download/41806/ title Broadcom Wi-Fi SoC - Heap Overflow in "wlc_tdls_cal_mic_chk" Due to Large RSN IE in TDLS Setup Confirm Frame type dos
Nessus
NASL family Fedora Local Security Checks NASL id FEDORA_2017-355AC8A91A.NASL description - Updated bcm 4339 4354 4356 4358 firmware, new bcm 43430 - Fixes CVE-2016-0801 CVE-2017-0561 CVE-2017-9417 Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues. last seen 2020-06-05 modified 2018-01-15 plugin id 105855 published 2018-01-15 reporter This script is Copyright (C) 2018-2020 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/105855 title Fedora 27 : linux-firmware (2017-355ac8a91a) code #%NASL_MIN_LEVEL 80502 # # (C) Tenable Network Security, Inc. # # The descriptive text and package checks in this plugin were # extracted from Fedora Security Advisory FEDORA-2017-355ac8a91a. # include("compat.inc"); if (description) { script_id(105855); script_version("3.5"); script_set_attribute(attribute:"plugin_modification_date", value:"2020/06/04"); script_cve_id("CVE-2016-0801", "CVE-2017-0561", "CVE-2017-9417"); script_xref(name:"FEDORA", value:"2017-355ac8a91a"); script_name(english:"Fedora 27 : linux-firmware (2017-355ac8a91a)"); script_summary(english:"Checks rpm output for the updated package."); script_set_attribute( attribute:"synopsis", value:"The remote Fedora host is missing a security update." ); script_set_attribute( attribute:"description", value: " - Updated bcm 4339 4354 4356 4358 firmware, new bcm 43430 - Fixes CVE-2016-0801 CVE-2017-0561 CVE-2017-9417 Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues." ); script_set_attribute( attribute:"see_also", value:"https://bodhi.fedoraproject.org/updates/FEDORA-2017-355ac8a91a" ); script_set_attribute( attribute:"solution", value:"Update the affected linux-firmware package." ); script_set_cvss_base_vector("CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C"); script_set_cvss_temporal_vector("CVSS2#E:POC/RL:OF/RC:C"); script_set_cvss3_base_vector("CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"); script_set_cvss3_temporal_vector("CVSS:3.0/E:P/RL:O/RC:C"); script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available"); script_set_attribute(attribute:"exploit_available", value:"true"); script_set_attribute(attribute:"plugin_type", value:"local"); script_set_attribute(attribute:"cpe", value:"p-cpe:/a:fedoraproject:fedora:linux-firmware"); script_set_attribute(attribute:"cpe", value:"cpe:/o:fedoraproject:fedora:27"); script_set_attribute(attribute:"vuln_publication_date", value:"2016/02/07"); script_set_attribute(attribute:"patch_publication_date", value:"2017/12/10"); script_set_attribute(attribute:"plugin_publication_date", value:"2018/01/15"); script_set_attribute(attribute:"generated_plugin", value:"current"); script_end_attributes(); script_category(ACT_GATHER_INFO); script_copyright(english:"This script is Copyright (C) 2018-2020 and is owned by Tenable, Inc. or an Affiliate thereof."); script_family(english:"Fedora Local Security Checks"); script_dependencies("ssh_get_info.nasl"); script_require_keys("Host/local_checks_enabled", "Host/RedHat/release", "Host/RedHat/rpm-list"); exit(0); } include("audit.inc"); include("global_settings.inc"); include("rpm.inc"); if (!get_kb_item("Host/local_checks_enabled")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED); release = get_kb_item("Host/RedHat/release"); if (isnull(release) || "Fedora" >!< release) audit(AUDIT_OS_NOT, "Fedora"); os_ver = pregmatch(pattern: "Fedora.*release ([0-9]+)", string:release); if (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, "Fedora"); os_ver = os_ver[1]; if (! preg(pattern:"^27([^0-9]|$)", string:os_ver)) audit(AUDIT_OS_NOT, "Fedora 27", "Fedora " + os_ver); if (!get_kb_item("Host/RedHat/rpm-list")) audit(AUDIT_PACKAGE_LIST_MISSING); cpu = get_kb_item("Host/cpu"); if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH); if ("x86_64" >!< cpu && cpu !~ "^i[3-6]86$") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, "Fedora", cpu); flag = 0; if (rpm_check(release:"FC27", reference:"linux-firmware-20171126-80.git17e62881.fc27")) flag++; if (flag) { security_report_v4( port : 0, severity : SECURITY_HOLE, extra : rpm_report_get() ); exit(0); } else { tested = pkg_tests_get(); if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested); else audit(AUDIT_PACKAGE_NOT_INSTALLED, "linux-firmware"); }NASL family Fedora Local Security Checks NASL id FEDORA_2017-A253644369.NASL description - Updated bcm 4339 4354 4356 4358 firmware, new bcm 43430 - Fixes CVE-2016-0801 CVE-2017-0561 CVE-2017-9417 ---- - Updated Intel GPU, amdgpu, iwlwifi, mvebu wifi, liquidio, QCom a530 & Venus, mlxsw, qed - Add iwlwifi 9000 series Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues. last seen 2020-06-05 modified 2017-12-11 plugin id 105133 published 2017-12-11 reporter This script is Copyright (C) 2017-2020 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/105133 title Fedora 26 : linux-firmware (2017-a253644369) code #%NASL_MIN_LEVEL 80502 # # (C) Tenable Network Security, Inc. # # The descriptive text and package checks in this plugin were # extracted from Fedora Security Advisory FEDORA-2017-a253644369. # include("compat.inc"); if (description) { script_id(105133); script_version("3.5"); script_set_attribute(attribute:"plugin_modification_date", value:"2020/06/04"); script_cve_id("CVE-2016-0801", "CVE-2017-0561", "CVE-2017-9417"); script_xref(name:"FEDORA", value:"2017-a253644369"); script_name(english:"Fedora 26 : linux-firmware (2017-a253644369)"); script_summary(english:"Checks rpm output for the updated package."); script_set_attribute( attribute:"synopsis", value:"The remote Fedora host is missing a security update." ); script_set_attribute( attribute:"description", value: " - Updated bcm 4339 4354 4356 4358 firmware, new bcm 43430 - Fixes CVE-2016-0801 CVE-2017-0561 CVE-2017-9417 ---- - Updated Intel GPU, amdgpu, iwlwifi, mvebu wifi, liquidio, QCom a530 & Venus, mlxsw, qed - Add iwlwifi 9000 series Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues." ); script_set_attribute( attribute:"see_also", value:"https://bodhi.fedoraproject.org/updates/FEDORA-2017-a253644369" ); script_set_attribute( attribute:"solution", value:"Update the affected linux-firmware package." ); script_set_cvss_base_vector("CVSS2#AV:N/AC:L/Au:N/C:C/I:C/A:C"); script_set_cvss_temporal_vector("CVSS2#E:POC/RL:OF/RC:C"); script_set_cvss3_base_vector("CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"); script_set_cvss3_temporal_vector("CVSS:3.0/E:P/RL:O/RC:C"); script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available"); script_set_attribute(attribute:"exploit_available", value:"true"); script_set_attribute(attribute:"plugin_type", value:"local"); script_set_attribute(attribute:"cpe", value:"p-cpe:/a:fedoraproject:fedora:linux-firmware"); script_set_attribute(attribute:"cpe", value:"cpe:/o:fedoraproject:fedora:26"); script_set_attribute(attribute:"vuln_publication_date", value:"2016/02/07"); script_set_attribute(attribute:"patch_publication_date", value:"2017/12/09"); script_set_attribute(attribute:"plugin_publication_date", value:"2017/12/11"); script_set_attribute(attribute:"generated_plugin", value:"current"); script_end_attributes(); script_category(ACT_GATHER_INFO); script_copyright(english:"This script is Copyright (C) 2017-2020 and is owned by Tenable, Inc. or an Affiliate thereof."); script_family(english:"Fedora Local Security Checks"); script_dependencies("ssh_get_info.nasl"); script_require_keys("Host/local_checks_enabled", "Host/RedHat/release", "Host/RedHat/rpm-list"); exit(0); } include("audit.inc"); include("global_settings.inc"); include("rpm.inc"); if (!get_kb_item("Host/local_checks_enabled")) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED); release = get_kb_item("Host/RedHat/release"); if (isnull(release) || "Fedora" >!< release) audit(AUDIT_OS_NOT, "Fedora"); os_ver = pregmatch(pattern: "Fedora.*release ([0-9]+)", string:release); if (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, "Fedora"); os_ver = os_ver[1]; if (! preg(pattern:"^26([^0-9]|$)", string:os_ver)) audit(AUDIT_OS_NOT, "Fedora 26", "Fedora " + os_ver); if (!get_kb_item("Host/RedHat/rpm-list")) audit(AUDIT_PACKAGE_LIST_MISSING); cpu = get_kb_item("Host/cpu"); if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH); if ("x86_64" >!< cpu && cpu !~ "^i[3-6]86$") audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, "Fedora", cpu); flag = 0; if (rpm_check(release:"FC26", reference:"linux-firmware-20171126-80.git17e62881.fc26")) flag++; if (flag) { security_report_v4( port : 0, severity : SECURITY_HOLE, extra : rpm_report_get() ); exit(0); } else { tested = pkg_tests_get(); if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested); else audit(AUDIT_PACKAGE_NOT_INSTALLED, "linux-firmware"); }NASL family Debian Local Security Checks NASL id DEBIAN_DLA-1573.NASL description Several vulnerabilities have been discovered in the firmware for Broadcom BCM43xx wifi chips that may lead to a privilege escalation or loss of confidentiality. CVE-2016-0801 Broadgate Team discovered flaws in packet processing in the Broadcom wifi firmware and proprietary drivers that could lead to remote code execution. However, this vulnerability is not believed to affect the drivers used in Debian. CVE-2017-0561 Gal Beniamini of Project Zero discovered a flaw in the TDLS implementation in Broadcom wifi firmware. This could be exploited by an attacker on the same WPA2 network to execute code on the wifi microcontroller. CVE-2017-9417 / #869639 Nitay Artenstein of Exodus Intelligence discovered a flaw in the WMM implementation in Broadcom wifi firmware. This could be exploited by a nearby attacker to execute code on the wifi microcontroller. CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081 Mathy Vanhoef of the imec-DistriNet research group of KU Leuven discovered multiple vulnerabilities in the WPA protocol used for authentication in wireless networks, dubbed last seen 2020-06-01 modified 2020-06-02 plugin id 118888 published 2018-11-13 reporter This script is Copyright (C) 2018-2019 and is owned by Tenable, Inc. or an Affiliate thereof. source https://www.tenable.com/plugins/nessus/118888 title Debian DLA-1573-1 : firmware-nonfree security update (KRACK)
Seebug
bulletinFamily exploit description 详细分析：https://googleprojectzero.blogspot.tw/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html Posted by Gal Beniamini, Project Zero It's a well understood fact that platform security is an integral part of the security of complex systems. For mobile devices, this statement rings even truer; modern mobile platforms include multiple processing units, all elaborately communicating with one another. While the code running on the application processor (AP) has been the subject of much research, other components have seldom received the same scrutiny.  Over the years, as a result of the focused attention by security folk, the defenses of code running on the application processor have been reinforced. Taking Android as a case study, this includes [hardening the operating system](https://source.android.com/security/overview/kernel-security.html), [improving the security of applications](https://source.android.com/security/overview/app-security.html), and introducing [incremental security enhancements](https://source.android.com/security/enhancements/enhancements70.html) affecting the entire system. All positive improvements, no doubt. However, attackers tend to follow the path of least resistance. Improving the security of one component will inevitably cause some attackers to start looking elsewhere for an easier point of entry. In this two-part blog series, we'll explore the exposed attack surface introduced by Broadcom's Wi-Fi SoC on mobile devices. Specifically, we'll focus our attention on devices running Android, although a vast amount of this research applies to other systems including the same Wi-Fi SoCs. The first blog post will focus on exploring the Wi-Fi SoC itself; we'll discover and exploit vulnerabilities which will allow us to remotely gain code execution on the chip. In the second blog post, we'll further elevate our privileges from the SoC into the the operating system's kernel. Chaining the two together, we'll demonstrate full device takeover by Wi-Fi proximity alone, requiring no user interaction. We'll focus on Broadcom's Wi-Fi SoCs since they are the most common Wi-Fi chipset used on mobile devices. A partial list of devices which make use of this platform includes the Nexus 5, 6 and 6P, most Samsung flagship devices, and all iPhones since the iPhone 4\. For the purpose of this blog post, we'll demonstrate a Wi-Fi remote code execution exploit on a fully updated (at the time) Nexus 6P, running Android 7.1.1 version NUF26K. All the vulnerabilities in the post have been disclosed to Broadcom. Broadcom has been incredibly responsive and helpful, both in fixing the vulnerabilities and making the fixes available to affected vendors. For a complete timeline, see [the](https://bugs.chromium.org/p/project-zero/issues/detail?id=1046) [bug](https://bugs.chromium.org/p/project-zero/issues/detail?id=1047) [tracker](https://bugs.chromium.org/p/project-zero/issues/detail?id=1051) [entries](https://bugs.chromium.org/p/project-zero/issues/detail?id=1059). They've also been very open to discussions relating to the security of the Wi-Fi SoC. I would like to thank Thomas Dullien ([@halvarflake](https://twitter.com/halvarflake)) for helping boot up the research, for the productive brainstorming, and for helping search the literature for any relevant clues. I'd also like to thank my colleagues in the London office for helping make sense of the exploitation constraints, and for listening to my ramblings. Why-Fi? In the past decade, the use of Wi-Fi has become commonplace on mobile devices. Gradually, Wi-Fi has evolved into a formidable set of specifications-some detailing the physical layer, others focusing on the MAC layer. In order to deal with this increased complexity, vendors have started producing "[FullMAC](https://en.wikipedia.org/wiki/Wireless_network_interface_controller#FullMAC_and_SoftMAC_devices)" Wi-Fi SoCs. In essence, these are small SoCs that perform all the PHY, MAC and MAC SubLayer Management Entity ([MLME](https://wireless.wiki.kernel.org/en/developers/documentation/glossary#mlme)) processing on their own, allowing the operating system 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 power 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, as they implement the MLME within their firmware, reducing the complexity on the host's side. All that said and done, the introduction of Wi-Fi FullMAC chips does not come without a cost. Introducing these new pieces of hardware, running proprietary and complex code bases, may weaken the overall security of the devices and introduce vulnerabilities which could compromise the entire system.  ### Exploring the Platform To start off our research, we'll need to find some way to explore the Wi-Fi chip. Luckily, [Cypress has recently acquired Broadcom's Wireless IOT business](http://www.cypress.com/news/cypress-acquire-broadcom-s-wireless-internet-things-business-0), and have published many of the [datasheets](http://www.cypress.com/file/298016/download) related to Broadcom's Wi-Fi chipsets (albeit for a slightly older SoC, the BCM4339). Reading through the datasheet, we gain some insight into the hardware architecture behind the Wi-Fi chipset.  Specifically, we can see that there's an ARM Cortex R4 core, which runs all the logic for handling and processing frames. Moreover, the datasheet reveals that the ARM core has 640KB of ROM used to hold the firmware's code, and 768KB of RAM which is used for data processing (e.g., heap) and to store patches to firmware code. To start analysing the code running on the ARM core, we'll need to extract the contents of the ROM, and to locate the data that is loaded into RAM. Let's start by tackling the second problem first - where is the data that's loaded into the ARM core's RAM? Since this data is not present in ROM, it must be loaded externally when the chip first powers on. Therefore, by reading through the initialisation code in the host's driver, we should be able to locate the file containing the RAM's contents. Indeed, going over the driver's code, we find the [BCMDHD_FW_PATH config](https://android.googlesource.com/kernel/common.git/+/bcmdhd-3.10/drivers/net/wireless/bcmdhd/Kconfig#32), which is used to denote the location of the file whose contents are [uploaded to RAM by the driver](https://android.googlesource.com/kernel/common.git/+/bcmdhd-3.10/drivers/net/wireless/bcmdhd/dhd_linux.c#5061). So what about the ROM's contents? One way to extract the ROM would be to use the host driver's chip memory 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 issue the commands needed to dump the ROM. Another way to retrieve the ROM would be to load our own modified firmware file into RAM, into which we'll insert a small stub that can be used to dump the ROM's memory range. Luckily, none of these approaches is actually needed in this case; Broadcom provides an extremely powerful command-line utility called [dhdutil](https://android.googlesource.com/platform/hardware/broadcom/wlan/+/master/bcmdhd/dhdutil/Android.mk), which can be used to interact with the chip via the bcmdhd driver. Among the various capabilities this utility supports, it also allows us to directly read and write memory on the dongle by issuing a special command - "membytes". Since we already know the size of the ROM (from the datasheet), we can just use the membytes command to read the ROM's contents directly. However, there's one last question we need to answer first - where is the ROM located? According to the [great](https://arxiv.org/pdf/1601.07077.pdf) [research](https://www.seemoo.tu-darmstadt.de/fileadmin/user_upload/Group_SEEMOO/mschulz/wisec2016-using_nexmon.pdf) done by the folks behind NexMon, the ROM is loaded at address 0x0, and the RAM is loaded at address 0x180000 (while NexMon focused on BCM4339, this fact remains true for newer chips as well, such as the BCM4358). Finally, putting all this together, we can acquire the RAM's contents from the firmware file, dump the ROM using dhdutil, and combine the two into a single file which we can then start analysing in IDA.  ### Analysing the Firmware Due to the relatively small size of the available memory (both ROM and RAM), Broadcom went to extreme efforts in order to conserve memory. For starters, they've stripped the symbols and most of the strings from the binary. This has the added bonus of making it slightly more cumbersome to reverse-engineer the firmware's code. They've also opted for using the Thumb-2 instruction set exclusively, which allows for better code density. As a result, the ROM image on the BCM4358 is so tightly packed that it contains less than 300 unused bytes. However, this is still not quite enough... Remember that the RAM has to accommodate the heap, stack and global data structures, as well as all the patches or modifications to ROM functions. Quite a tall order for a measly 768KB. To get around this, Broadcom has decided to place all the functions that are only used during the firmware's initialisation in two special regions. Once the initialisation is completed, these regions are "reclaimed", and are thereafter converted into heap chunks. What's more, heap chunks are interspersed between code and data structures in RAM - since the latter sometimes have alignment requirements (or are referenced directly from ROM, so they cannot be moved). The end result is that RAM is a jumbled mess of heap chunks, code and data structures.  After spending some time analysing the firmware, we can begin identifying at least a few strings containing function names and other hints, helping us get a grasp of the code base. Additionally, the NexMon researchers have [released their gathered symbols](https://github.com/seemoo-lab/bcm-public/blob/master/buildtools/mapaddr/firmware.map) corresponding to firmware on the BCM4339\. We can apply the same symbols to the BCM4339's firmware, and then use [bindiff](https://www.zynamics.com/bindiff.html) to correlate the symbol names in newer firmware versions for more recent chips. Lastly, there's one more trick in our hat - Broadcom produces SoftMAC chips in addition to the FullMAC SoCs we're analysing. Since these SoftMAC chips don't handle the MLME layer, their corresponding driver must perform that processing. As a result, much of Broadcom's MLME processing code is included in the open-source SoftMAC driver - [brcmsmac](https://github.com/torvalds/linux/tree/master/drivers/net/wireless/broadcom/brcm80211/brcmsmac). While this won't help us out with any of the chip-specific features or the more internal processing code, it does seem to share many utility functions with the firmware's code. Hunting for Bugs Now that we have a grasp of the firmware's structure and have the means to analyse it, we can finally start hunting for bugs. But... Where should we start? Even with all the tricks mentioned before, this is a relatively large and opaque binary, and strings or symbols are few and far between. One possibility would be to instrument the firmware in order to trace the code paths taken while a packet is received and processed. The Cortex R4 does, indeed, have [debug registers](http://infocenter.arm.com/help/topic/com.arm.doc.ddi0363g/Bcgjfchg.html) which can be used to place breakpoints and inspect the code flow at various locations. Alternately, we could manually locate a set of functions which are used to parse and retrieve information from a received frame, and work our way backwards from there. This is where familiarity with Wi-Fi comes in handy; Wi-Fi management frames encode most of their information in small "tagged" chunks of data, called Information Elements (IEs). These tagged chunks of data are structured as [TLVs](https://en.wikipedia.org/wiki/Type-length-value), where the tag and length fields are a single byte long.  Since a large portion of the information transferred in Wi-Fi frames (other than the data itself) is encoded using IEs, they make for good candidates from which we can work our way backwards. Moreover, as "tag" values are [unique and standardised](http://dox.ipxe.org/group__ieee80211__ie.html), we can use their values to help familiarise ourselves with the currently handled code flow. Looking at the brcmsmac driver, we can see that there's a single function which Broadcom uses in order to extract IEs from a frame - [bcm_parse_tlvs](http://lxr.free-electrons.com/source/drivers/staging/brcm80211/util/bcmutils.c?v=2.6.37#L761). After a brief search (by correlating hints from nearby strings), we find the same function in the firmware's ROM. Great. Now we can start cross-referencing locations which call this function, and reverse each of these call-sites. While substantially easier than reversing every part of the firmware, this still takes a considerable amount of time (as the function has more than 110 cross-references, some to other wrapper functions which themselves are called from multiple locations). After reverse engineering all of the call sites, I've [found](https://bugs.chromium.org/p/project-zero/issues/detail?id=1046) [a](https://bugs.chromium.org/p/project-zero/issues/detail?id=1047) [few](https://bugs.chromium.org/p/project-zero/issues/detail?id=1051) [vulnerabilities](https://bugs.chromium.org/p/project-zero/issues/detail?id=1059) related to the handling of information elements embedded in management frames. Two of the vulnerabilities can be triggered when connecting to networks supporting wireless roaming features; 802.11r Fast BSS Transition (FT), or Cisco's CCKM roaming. On the one side, these vulnerabilities should be relatively straightforward to exploit - they are simple stack overflows. Moreover, the operating system running on the firmware (HNDRTE) does not use stack cookies, so there's no additional information leak or bypass required. However, while these vulnerabilities may be comfortable to exploit, they require some set-up to get working. First, we'd need to broadcast Wi-Fi networks that support these features. [802.11r FT](https://en.wikipedia.org/wiki/IEEE_802.11r-2008) is an [open(-ish) standard](https://standards.ieee.org/findstds/standard/802.11-2016.html), and is implemented by hostapd. In contrast, CCKM is a proprietary standard (although [some](https://supportforums.cisco.com/document/11086/what-cckm-and-how-does-it-affect-fast-and-secure-roaming) [information](http://www.cisco.com/c/en/us/support/docs/wireless-mobility/wireless-lan-wlan/116493-technote-technology-00.html#anc8) can be found online). Figuring out how to emulate a CCKM network (or buying a CCKM-capable [WLC](http://www.cisco.com/c/en/us/products/wireless/wireless-lan-controller/index.html) from Cisco) would be cumbersome (or costly). Additionally, we'd need to figure out which devices actually support the aforementioned features. Broadcom provides many features which can be licensed by customers -- not all features are present on all devices (in fact, their corresponding patches probably wouldn't even fit in RAM). Luckily, Broadcom makes it easy to distinguish which features are actually present in each firmware image. The last few bytes in the RAM contents downloaded to the chip contain the firmware's "version string". This string contains the date at which the firmware was compiled, the chip's revision, the firmware's version and a list of dash-delimited "tags". Each tag represents a feature that is supported by 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 feature is indicated by the "fbt" tag. Similarly, support for CCKM is indicated by the "ccx" tag. Unfortunately, it seems that the Nexus 6P supports neither of these features. In fact, running a quick search for the "ccx" feature (CCKM support) on my own repository of Android firmware images revealed that this feature is not supported on any Nexus device, but is supported on a wide variety of Samsung flagship devices, a very partial list of which includes the Galaxy S7 (G930F, G930V), the Galaxy S7 Edge (G935F, G9350), the Galaxy S6 Edge (G925V) and many more. So what about the other two vulnerabilities? Both of them relate to the implementation of Tunneled Direct Link Setup ([TDLS](https://en.wikipedia.org/wiki/TDLS)). TDLS connections allow peers on a Wi-Fi network to exchange data between one another without passing it through the Access Point (AP), thus preventing congestion at the AP. Support for TDLS in the firmware is indicated by the "betdls" and "tdls" tags. Searching through my firmware repository I can see that the vast majority of devices do, indeed, support TDLS. This includes all recent Nexus devices (Nexus 5, 6, 6P) and most Samsung flagships. What's more, TDLS is specified as part of the [802.11z standard](http://ieeexplore.ieee.org/document/5605400/) (requires IEEE subscription). Since all the information regarding TDLS is available, we could read the standard in order to gain familiarity with the relevant code paths in Broadcom's implementation. As an open standard, it is also supported by open-source supplicants, such as [wpa_supplicant](https://w1.fi/wpa_supplicant/). As a result, we can inspect the implementation of the TDLS features in wpa_supplicant in order to further improve our understanding of the relevant code in the firmware. Lastly, as we'll see later on, triggering these two vulnerabilities can be done by any peer on the Wi-Fi network, without requiring any action on the part of the device being attacked (and with no indication that such an attack is taking place). This makes these vulnerabilities all the more interesting to explore. In any case, it seems like we've made our mind up! We're going to exploit the TDLS vulnerabilities. Before we do so, however, let's take a second to learn a little bit about TDLS, and the vulnerabilities discovered (skip this part it you're already familiar with TDLS). 802.11z TDLS 101 There are many use cases where two peers on the same Wi-Fi network wish to transfer large swaths of data between one another. For example, casting a video from your mobile device to your Chromecast would require large amounts of data to be transmitted. In most cases, the Chromecast would be relatively nearby to the caster (after all, you'd probably be watching the screen to which you're casting). Therefore, it would seem wasteful to pass the entire data stream from the device to the AP, only to then pass it on to the Chromecast. It's not just the increased latency of adding an additional hop (the AP) that will degrade the connection's quality. Passing such large amounts of data to the AP would also put a strain on the AP itself, cause congestion, and would degrade the Wi-Fi connectivity for all peers on the network. This is where TDLS comes into play. TDLS is meant to provide a means of peer-to-peer communication on a Wi-Fi network that is AP-independant. Over The Air Let's start by familiarising ourselves with the structure of TDLS frames. As you may know, 802.11 frames use the "flags" field in order to indicate the "direction" in which a frame is travelling (from the client to the AP, AP to client, etc.). TDLS traffic co-opts the use of the flag values indicating traffic in an Ad-Hoc (IBSS) network (To-DS=0, From-DS=0).  Next, TDLS frames are identified by a special ethertype value - 0x890D. TDLS frames transmitted over Wi-Fi use [a constant value](http://lxr.free-electrons.com/source/include/linux/ieee80211.h?v=4.5#L2083) in the "payload type" field, indicating that the payload has the following structure:  The category for TDLS frames is also set to [a constant value](http://lxr.free-electrons.com/source/include/linux/ieee80211.h#L2001). This leaves us with only one field which distinguishes between different TDLS frame types - the "action code". This 1-byte field indicates the kind of TDLS frame we're transmitting. This, in turn, controls the way in which the "payload" in interpreted by the receiving end. High-Level Flow Before two peers can establish a connection, they must first know about the existence of one another. This is called the "discovery" phase. A Wi-Fi client that wishes to discover TDLS-capable peers on the network, can do so by sending a "TDLS Discovery Request" frame to a peer. A TDLS-capable peer that receives this frame, responds by sending a "TDLS Discovery Response" frame. The request and response are correlated to one another using a 1-byte "dialog token".  Next, the peers may wish to set up a connection. To do so, they must perform a 3-way handshake. This handshake serves a dual purpose; first, it indicates that a connection is successfully established between the two peers. Second, it's used to derive the TDLS Peer Key (TPK), which secures the TDLS traffic between the peers.  Finally, once the connection is created, the two peers can exchange peer traffic between one another. When one of the peers wishes to tear-down the connection, they may do so by sending a "TDLS Teardown" frame. Upon reception of such a frame, the TDLS-peer will remove the connection and free up all the related resources. Now that we know enough about TDLS, let's take a closer look at the vulnerabilities at hand! id SSV:92894 last seen 2017-11-19 modified 2017-04-05 published 2017-04-05 reporter Root title Broadcom: Heap overflow in TDLS Teardown Request while handling Fast Transition IE (CVE-2017-0561) bulletinFamily exploit description Broadcom produces the Wi-Fi HardMAC SoCs which are used to handle the PHY and MAC layer processing. These chips are present in both mobile devices and Wi-Fi routers, and are capable of handling many Wi-Fi related events without delegating to the host OS. One of the events handled by the BCM firmware is the processing of TDLS connections (802.11 z). TDLS connections allow clients to exchange data between one another without passing it through the AP (thus preventing congestion at the AP). In order to verify the integrity of TDLS messages, each message exchanged between the TDLS peers includes a message integrity code (MIC). The MIC is calculated using AES-CMAC with a key derived during the setup process (TPK-KCK). When a TDLS Setup Request frame is sent by either one of the peers in an established TDLS connection, the receiving client must verify the MIC before processing the request. The MIC for TDLS Setup Request and TDLS Setup Confirm frames is calculated as follows: `AES-CMAC(TPK-KCK, InitiatorMAC || ResponderMAC || TransactionSeq || LinkID-IE || RSN-IE || TimeoutInterval-IE || FastTransition-IE)` (see "wpa_tdls_ftie_mic" under https://w1.fi/cgit/hostap/plain/src/rsn_supp/tdls.c) All TDLS connections are accepted automatically from any peer and are handled solely by the BCM firmware (meaning there is no need for user interaction or involvement in any way - once a TDLS Setup Request is received by the firmware, it will proceed with the TDLS handshake and subsequently create a TDLS connection with the requesting peer). When the BCM firmware receives a TDLS Setup request frame, it verifies the MIC and responds with a TDLS Setup Response frame. The initiator then sends a TDLS Setup confirm frame in order to establish the connection. The BCM firmware uses the "`wlc_tdls_cal_mic_chk`" function to calculate the MIC of the received frames (both for the setup and the confirm). When processing the TDLS Setup Request frame, the RSN IE is verified and parsed in order to proceed with the derivation of the TPK. This verification also makes sure that the length of the RSN IE is valid for the chosen encryption type. However, when a TDLS Setup Confirm (M3) message is received, the firmware fails to verify the RSN IE, before calling the "`wlc_tdls_cal_mic_chk`" function in order to verify the MIC of the incoming frame. The "wlc_tdls_cal_mic_chk" function allocates a buffer of size 256 on the heap, into which the needed information elements are gathered in order to calculate the AES-CMAC. However, the function does not sufficiently verify the length of the RSN IE included in the Setup Confirm frame. This allows an attacker to include an abnormally large RSN IE, causing a heap-overflow in "wlc_tdls_cal_mic_chk". Here is the approximate simplified high-level code for the function: `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 can be seen above, although the function verifies that the RSN IE's length does not exceed the allocated buffer (line 13), it fails to verify that the subsequent IEs also do not overflow the buffer. As such, setting the RSN IE's length to a large value (i.e., such that rsn_ie[1] + 2 + (pos - buffer) == 0xFF) will cause the Timeout Interval and a Fast Transition IEs to be copied out-of-bounds, on paying the buffer. It should be noted that prior to calculating the MIC, the function in charge of processing the TDLS Setup Confirm frame calls a helper function in order to verify the nonce values in the FTIE (to make sure they match the nonces in the TDLS Setup Request and TDLS Setup Response frames, M1 & M2). However, since the attacker is the initiator of the TDLS connection, they may choose the value of Snonce (bytes [52-84) of the FTIE) arbitrarily. This leaves only the Anonce (bytes [20-52) of the FTIE) as uncontrolled bytes during the overflow, since they are chosen by the responder. It should also be noted that the heap implementation used in the BCM firmware does not perform safe unlinking or include the heap header cookie, allowing heap overflows such as the one described above to be exploited more reliably. I'm attaching a patch to wpa_supplicant 2.6 which modifies the TDLS Setup Confirm frame sent by the supplicant in order to trigger the heap overflow. You can reproduce the issue by following these steps: 1. Download wpa_supplicant 2.6 from https://w1.fi/releases/wpa_supplicant-2.6.tar.gz 2. Apply the included patch file 3. Build wpa_supplicant (with TDLS support) 4. Use wpa_supplicant to connect to a network 5. Connect to wpa_cli: 5.1. Setup a TDLS connection to the BCM peer using "TDLS_SETUP " (Where MAC_ADDRESS_OF_PEER is the MAC address of a peer with a BCM SoC which is associated to the same network). At this point, the heap overflow will be triggered. The code in the patch will corrupt the heap, causing the remote BCM SoC to reset after a while. I've been able to verify this vulnerability on the BCM4339 chip, running version 6.37.34.40 (as present on the Nexus 5). However, I believe this vulnerability's scope includes a wider range of Broadcom SoCs and versions. Attachments: [patch](<https://bugs.chromium.org/p/project-zero/issues/attachment?aid=264245>) id SSV:92903 last seen 2017-11-19 modified 2017-04-05 published 2017-04-05 reporter Root title Broadcom: Heap overflow in "wlc_tdls_cal_mic_chk" due to large RSN IE in TDLS Setup Confirm frame (CVE-2017-0561)