Vulnerability Note VU#106678
IEEE 802.11 wireless network protocol DSSS CCA algorithm vulnerable to denial of service
The IEEE 802.11 wireless networking protocol contains a vulnerability that could allow a remote attacker to cause a denial of service to any wireless device within range.
IEEE 802.11 wireless network protocols use a Clear Channel Assessment (CCA) algorithm to determine whether or not the radio frequency (RF) channel is clear so that a device on the network can transmit data. The CCA algorithm used in conjunction with Direct Sequence Spread Spectrum (DSSS) transmission is vulnerable to an attack in which a specially crafted RF signal (PLME_DSSSTESTMODE) will cause the algorithm to conclude that the channel is busy, so that no device in range of the signal will transmit data. This type of signal is sometimes called "jabber." The attacker must be actively transmitting a signal and within range to affect wireless devices.
This vulnerability is more thoroughly documented in AusCERT Advisory AA-2004.02. AusCERT notes that devices that use 802.11 and DSSS transmission encoding are affected:
Wireless hardware devices that implement IEEE 802.11 using a DSSS physical layer. Includes IEEE 802.11, 802.11b and low-speed (below 20Mbps) 802.11g wireless devices. Excludes IEEE 802.11a and high-speed (above 20Mbps) 802.11g wireless devices.
This is not an implementation vulnerability; any 802.11 DSSS device, including wireless network cards and access points, is vulnerable. WEP, WPA, or other WLAN security features will not protect vulnerable devices. As explained in a Technical Summary by researchers at the Queensland University of Technology (QUT) Information Security Research Centre (ISRC), this vulnerability exists in the Packet Layer Convergence Procedure (PLCP) layer, below the MAC layer. MAC layer security will not mitigate this vulnerability.
It is worth noting that since 802.11 management frames are weakly authenticated (VU#391513), it is possible for an attacker to DoS an 802.11 network by sending de-authentication or failed authentication frames using the spoofed MAC and IP addresses of an access point. Tools that perform this type of attack are publicly available (FATA-jack, airjack, wlan-jack). While the CCA attack may be less expensive for an attacker, both attacks have similar characteristics (active attacker in range using commodity hardware) and impacts (DoS while attacker is in range and active). Wireless networks in general are also subject to RF interference or jamming. Careful consideration should be given to the use of commercial grade wireless networks for applications that require high availability.
An unauthenticated, remote attacker can cause any vulnerable device within range to stop transmitting, causing a denial of service.
A complete solution is not available for 802.11 DSSS devices. As noted by AusCERT, "...a comprehensive solution, in the form of software or firmware upgrade, is not available for retrofit to existing devices. Fundamentally, the issue is inherent in the protocol implementation of IEEE 802.11 DSSS." Sites running wireless networks should consider security and availability requirements, network design, and the workarounds listed below.
Use non-DSSS 802.11 protocols
802.11 protocols that use frequency hopping spread spectrum (FHSS) or orthogonal frequency division multiplexing (OFDM) are not affected by this vulnerability. 802.11a uses OFDM, 802.11 can use FHSS, and 802.11g can use OFDM. Note that this workaround will not provide protection against management frame spoofing or RF attacks.
Constrain wireless networks
Depending on the application and site infrastructure, it may be possible to prevent attackers from getting in range of 802.11 networks by using physical barriers (walls, fences, elevation, etc.). In addition, different building materials provide various degrees of shielding.
Do not rely on 802.11 for high availability
Due to the inherent vulnerabilities in 802.11 (VU#106678, VU#391513, RF interference), do not deploy 802.11 networks for applications that require high availability (e.g. safety, critical infrastructure).
If you are a vendor and your product is affected, let
us know.View More »
|Vendor||Status||Date Notified||Date Updated|
|Aruba Networks||Affected||12 May 2004||07 Jun 2004|
|3Com||Unknown||-||13 May 2004|
|Alcatel||Unknown||-||13 May 2004|
|Apple Computer, Inc.||Unknown||-||13 May 2004|
|AT&T||Unknown||-||13 May 2004|
|Avaya||Unknown||-||13 May 2004|
|Cisco Systems, Inc.||Unknown||-||13 May 2004|
|D-Link Systems||Unknown||-||13 May 2004|
|Extreme Networks||Unknown||-||13 May 2004|
|Foundry Networks Inc.||Unknown||-||13 May 2004|
|Hewlett-Packard Company||Unknown||-||13 May 2004|
|IBM Corporation||Unknown||-||13 May 2004|
|Juniper Networks, Inc.||Unknown||-||13 May 2004|
|Linksys||Unknown||-||13 May 2004|
|Lucent Technologies||Unknown||-||13 May 2004|
This vulnerability was researched by the Queensland University of Technology (QUT) Information Security Research Centre (ISRC) and coordinated by the Australian Computer Emergency Response Team (AusCERT).
This document was written by Art Manion.
12 May 2004
Date First Published:
13 May 2004
Date Last Updated:
15 Feb 2008
If you have feedback, comments, or additional information about this vulnerability, please send us email.