#963: [patch] Channel Switch Announcement remote abuse fix / reliability
improvement
---------------------------------+------------------------------------------
Reporter: [EMAIL PROTECTED] | Owner:
Type: defect | Status: new
Priority: blocker | Milestone: version 0.9.3
Component: madwifi: other | Version: v0.9.2
Resolution: | Keywords:
Patch_attached: 1 |
---------------------------------+------------------------------------------
Changes (by mrenzmann):
* milestone: => version 0.9.3
* priority: major => blocker
* version: => v0.9.2
Comment:
The description of the referenced external ticket is as follows:
{{{
#!blockquote
Currently, channel switch is performed only after receiving Channel Switch
Announcement with Channel Switch Count <= 1. This ensures proper operation
under normal conditions. However, Beacon misses happen (especially if
there is a reason to leave the current channel). If the last Beacon before
channel switch is lost, then STA will remain on the channel. Such a
condition is not fatal, because STA will eventually recover after some
time (by scanning for the BSS and rejoining). It is not optimal, though.
The information that a channel switch is scheduled could have been already
known thanks to prior announcements. Ignoring them is just losing the
opportunity to work fluently under harsh conditions.
Of course it has a drawback. The last (lost) Beacon before scheduled
channel switch could cancel it. If so, then our STA will change the
channel, notice that there is no one to talk to there and then try recover
as usual. However, if we lose last Beacon it is more probable that the
channel switch was not cancelled and thus assuming that we decrease the
probability of missing (or performing an incorrect) channel switch.
BTW It is desirable to pay more attention to received Channel Switch
Announcements to avoid malicious packet injections that can cause a
serious DoS.
}}}
There is currently one comment to that ticket, saying:
{{{
#!blockquote
Unfortunately, the "BTW" remark appeared to be true. Using extremely
simple packet injection, an attacker can send his own Beacon Frames with
Channel Switch Announcement Information Elements. If he sets CS Count <=
1, then the client station (madwifi in STA (Managed) mode) follows it
blindly and changes its operating channel. This completely interrupts
communication for a significant period of time (up to 10 seconds) and
therefore current design can be considered as a serious flaw allowing the
attacker to perform DoS attack easily.
The idea to monitor all incoming CSA IEs gives a possibility to avoid such
attacks or at least to reduce their impact to the minimum. Its
implementation has been applied as r962. Its functionality in brief:
* IEEE80211_CSA_PROTECTION_PERIOD has been introduced. It defines the
minimal Channel Switch Count in the initial packet. This means that the
period in which Channel Switch is announced cannot be too short. This
protects the client from switching to another channel after receiving
malicious CSA IE with Count <= 1.
* Interval measurement between subsequent CSA IEs is checked against the
actual CSA Count drop and the right multiplicity of Beacon Interval. It
allows to react to injected packets. The actual action is to cancel the
switch. It is not the ideal solution because now it is easy to enforce
cancelling the switch. However, not to switch is better than to switch ;D,
because the worst impact possible is disruption of communication for a few
seconds needed to scan the band to find the AP. But this can potentially
happen only when the switch is really going to happen and cannot be
triggered by the attacker.
* CSA parameters (Chan, Mode) are monitored for change.
* Channel to switch to is looked up after receiving first CSA IE.
* When any proper CSA IE is received, a timer is set up to make the
switch proceed even though the terminal CSA IE has not arrived. This
addresses the main task described in the ticket description.
The applied changes work fine and do much (if not the most) of what was
possible to ensure proper functioning while using available IEEE802.11h
facilities.
}}}
--
Ticket URL: <http://madwifi.org/ticket/963>
MadWifi <http://madwifi.org/>
Multiband Atheros Driver for Wireless Fidelity-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Madwifi-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/madwifi-tickets
