|
|||||||||||
|
if_wi_hostap.c kernel dos all versions openbsd
From: <merith(at)vantronix.net>
Date: Sat Dec 28 2002 - 10:27:14 EST
the openbsd 802.11b wireless hostap module contains a bug which freezes the system or slowes it down until it ist no more usable. all tested openbsd versions (3.0,3.1,3.2,3.2-current) are affected. the bug was found by reyk@vantronix.net while testing different wireless accesspoint implementations. you can verify the bug with the void11_penetration tool from http://www.wlsec.net/void11/ . at the moment we just tested the auth attack. a small patch is at the end of this mail (load testing was not possible because the wlan on the 19c3 is not suited for test) problem description: wihap_shutdown - when all (or many) slots for aviable stations are used, shutting down the ap causes the wifi card to die because all staions are killed linear from the beginning of the LIST() to the end .. sending 2 frames for every staion (disassoc and deauth). the system opens to much calls to wihap_sta_deauth() which calls wi_mgmt_xmit() which calls wi_cmd() ... at some point the card returns "command error" in the result field from the STATUS register. "wi_mgmt_xmit: xmit failed" is the displayed kernel message and the system hangs. sometimes it is possible to get into ddb from the console sometimes not. sometimes the system even comes back to life (if not all station slots are used) but the systems is not more stable (got some panics in tsleep(no trace and ps at the moment sorry)). fix: use broadcast to deauth all station. see hostapd for linux implementation or void11 type 1 attack. i could not verify if the deauth works correct (systems says so but we could not sniff the frames here on the 19c3). wihap_sta_timeout - i added a small delay to prevent instant call of disassoc or deauth. if the stations times out is it really neccessary to call wihap_sta_disassoc()? timout_* - when attacking a ap we get aprox. 50-100 station entrys per second. the granularity of the hardclock is not fine enought and wihap_sta_timeout() calls generate peaks in the system wich causes the same error like wihap_shutdown() routine. i tried to add more saturation to the timeout scala by adding a casted arc4random() value to every timeout_add() (to every because i think the system overhead for calling arc4random() is lower and the saturation is better when added for every timeout_add() reset) wihap_auth_req - if we reach the WIHAP_MAX_STATIONS limit we have either a very very big segment and the responsible admin should recompile the driver with a new limit or we are under attack. so we just return and dont send a frame back. note: would it be desireble to have a counter which saves failed commands and resets the card after a predefined amount of failures (either soft or hard) eg. in wi_cmd? bye mer fix:
+ DELAY(100);
if (sta->flags & WI_SIFLAGS_ASSOC) {
if (sc->sc_arpcom.ac_if.if_flags & IFF_DEBUG)
@@ -772,5 +781,6 @@ sta->flags |= WI_SIFLAGS_ASSOC; - timeout_add(&sta->tmo, hz * whi->inactivity_time); + timeout_add(&sta->tmo, + hz * (whi->inactivity_time + (u_int8_t) arc4random())); status = IEEE80211_STATUS_SUCCESS;Received on Sun Dec 29 22:24:38 2002 This archive was generated by hypermail 2.1.8 : Wed Aug 23 2006 - 13:29:43 EDT |
||||||||||
|
|||||||||||