Ticket #880 (closed defect: fixed)

Opened 2 years ago

Last modified 4 weeks ago

malicious ad-hoc auth frame crashes the system

Reported by: kurth@informatik.hu-berlin.de Assigned to:
Priority: blocker Milestone: version 0.9.3
Component: madwifi: driver Version: v0.9.2
Keywords: Cc:
Patch is attached: 1

Description

We created an ad-hoc device and started the olsrd on that interface. After sending a malicious auth frame from another host the system crashes. The frame which crashes the driver is a normal auth frame, except that the first address of the wifi header does not contain a valid mac address but the bssid of the ad-hoc network, i.e.

addr1: bssid

addr2: source address

addr3: bssid (same as addr1).

We are using Madwifi 0.9.3 on MIPS/Linux 2.6.16 (Netgear WGT634U).

Attachments

madwifi_ibss_auth_frame_crash.patch (0.7 kB) - added by jal2@gmx.de on 10/20/06 23:34:16.
Fixes a crash when an IBSS node receives an AUTH frame. Signed-off-by: Joerg Albert <jal2@gmx.de>
trace.jpg (88.3 kB) - added by someone@berkeley.edu on 01/18/07 03:50:14.
screenshot of the crash

Change History

09/14/06 06:09:50 changed by mrenzmann

  • version set to v0.9.2.
  • milestone deleted.

System crashes are in many cases accompanied by kernel oopses. Can you please try to get a dump of such an oops? DevDocs/AthDebug explains how that can be achieved.

09/14/06 06:11:56 changed by mrenzmann

Sorry, it's too early for me. DevDocs/KernelOops is the correct page.

09/14/06 10:59:24 changed by anonymous 

switch to AUTH state when operating in mode 0Break instruction in kernel code[#1]:
Cpu 0
$ 0   : 00000000 10009c00 00000030 802268f4
$ 4   : 802268f4 81231ed4 00000001 8028caa4
$ 8   : 8122e908 811cc380 00000000 00000000
$12   : fffffffb 0000000a 00000000 ffffffff
$16   : 00000002 81f52000 81f4d280 803c6280
$20   : 000000b0 00000004 803c6000 803c6280
$24   : 00000000 2ab88910
$28   : 80222000 80223b68 00000002 c00ece04
Hi    : 00000240
Lo    : 000001f8
epc   : c00ece04 __ieee80211_newstate+0x388/0x93c [wlan]     Tainted: P
ra    : c00ece04 __ieee80211_newstate+0x388/0x93c [wlan]
Status: 10009c03    KERNEL EXL IE
Cause : 00000024
PrId  : 00029007
Modules linked in: ath_pci wlan_scan_ap ath_rate_sample wlan ath_hal ipt_MASQUERADE ipt_REDIRECT iptable_nat iptable_filter ip_nat xt_tcpudp xt_conntrack ip_conntrack ip_tables x_tables sb_watchdog af_packet unix 
Process swapper (pid: 0, threadinfo=80222000, task=802250e8) 
Stack : 81873a10 c00fbdf0 00000000 000036c3 a1f02a60 8131d000 803c6280 81f4d280
        00000004 81f52000 00000002 000000b0 c00ed624 00000050 8122d1b5 c007b5d0
        803c6280 803c6000 c00ace3c c007c798 fffa0000 803c6280 81f30000 81f52000
        00000000 81f4d280 c00864ac c0086040 00000040 00000000 0000007b 80223c40
        81efaa80 00000000 00000000 800510f0 00000197 803c79f0 8131d000 81f4d280
        ...
Call Trace:
 [<c00ed624>] ieee80211_newstate+0x26c/0x294 [wlan]  
 [<c007b5d0>] ath_mgtstart+0x2b8/0x54c [ath_pci] 
 [<c00ace3c>] zz016e648a+0x30/0xbc [ath_hal] 
 [<c007c798>] ath_calcrxfilter+0x24/0xa4 [ath_pci] 
 [<c00864ac>] ath_newstate+0x744/0x910 [ath_pci] 
 [<c0086040>] ath_newstate+0x2d8/0x910 [ath_pci] 
 [<800510f0>] handle_IRQ_event+0x64/0xd8 
 [<c00eca54>] ieee80211_new_state+0x24/0x4c [wlan] 
 [<c00dbed8>] ieee80211_auth_open+0x3b4/0x3d4 [wlan] 
 [<80037b14>] update_process_times+0x74/0x88 
 [<80037b0c>] update_process_times+0x6c/0x88 
 [<80037a44>] update_wall_time+0x18/0x74 
 [<c00debd4>] ieee80211_recv_mgmt+0x1210/0x24ec [wlan] 
 [<80001d54>] bcm47xx_irq_handler+0xf4/0x100 
 [<8000f784>] do_gettimeofday+0x2c/0x130 
 [<80025488>] activate_task+0x54/0xc4 
 [<c007ffbc>] ath_recv_mgmt+0x4c/0x200 [ath_pci] 
 [<80032710>] getnstimeofday+0x18/0x4c 
 [<800491d4>] ktime_get_real+0x18/0x3c 
 [<c00daad8>] ieee80211_input+0x1228/0x13ac [wlan]  
 [<800255fc>] try_to_wake_up+0xbc/0x1b4 
 [<8004073c>] delayed_work_timer_fn+0x0/0x24 
 [<80049198>] ktime_get+0x18/0x3c 
 [<800491d4>] ktime_get_real+0x18/0x3c 
 [<80018090>] dma_sync_single_for_cpu+0x6c/0x84 
 [<c00807cc>] ath_rx_tasklet+0x604/0x950 [ath_pci] 
 [<8003308c>] tasklet_action+0x108/0x178 
 [<80032b38>] __do_softirq+0x68/0xf8 
 [<8000b06c>] do_IRQ+0x24/0x34 
 [<80032c20>] do_softirq+0x58/0x8c  
 [<8005122c>] __do_IRQ+0xc8/0x12c 
 [<80051208>] __do_IRQ+0xa4/0x12c 
 [<80032d24>] irq_exit+0x40/0x4c 
 [<8000b06c>] do_IRQ+0x24/0x34 
 [<80001be4>] bcm47xx_irq_dispatch+0x64/0xe0  
 [<80257000>] kernel_entry+0x0/0x7c 
 [<80001d54>] bcm47xx_irq_handler+0xf4/0x100 
 [<80257000>] kernel_entry+0x0/0x7c 
 [<8000b280>] cpu_idle+0x50/0x58  
 [<8000b254>] cpu_idle+0x24/0x58 
 [<8000143c>] rest_init+0x2c/0x38 
 [<80001434>] rest_init+0x24/0x38 
 [<802577d0>] start_kernel+0x1f4/0x200 
 [<802577ac>] start_kernel+0x1d0/0x200 
 [<8025721c>] unknown_bootoption+0x0/0x228


Code: 2442c6c8  0040f809  00000000 <0000800d> 2ea20005  10400161  8fbf0030  00151080  3c01c010 Kernel panic - not syncing: Aiee, killing interrupt handler!
 <0>Rebooting in 3 seconds..

09/14/06 19:27:52 changed by mentor

  • priority changed from major to blocker.

09/16/06 21:24:19 changed by mentor

Hmmm. Why is bcm47xx_irq_handler in there?

Could you provide more information? Is the crashed MadWifi stack operating as a station interface or access point? I assume you are using the Open System Authentication Algorithm?

09/17/06 01:15:45 changed by mentor

Ah. I think the problem here is that we have no concept of which nodes are local or not.

09/17/06 20:21:38 changed by kurth@informatik.hu-berlin.de

The device operates in adhoc mode (wlanconfig ... wlanmode adhoc). I'm not sure which auth algorithm is used by default, perhops you can tell me where I can find this information.

09/20/06 03:48:36 changed by mentor

Could you add the output of iwconfig and ifconfig for the setup that fails?

09/24/06 17:04:23 changed by anonymous 

$ ifconfig
ath0      Link encap:Ethernet  HWaddr 00:0F:B5:3F:21:3C
          inet addr:104.142.0.66  Bcast:104.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:2290  Metric:1
          RX packets:127290 errors:0 dropped:0 overruns:0 frame:0
          TX packets:133690 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:9725037 (9.2 MiB)  TX bytes:10258700 (9.7 MiB)

eth0      Link encap:Ethernet  HWaddr 00:0F:B5:3F:4E:72
          inet addr:192.168.3.24  Bcast:192.168.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:241948 errors:0 dropped:0 overruns:0 frame:0
          TX packets:140376 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:29919825 (28.5 MiB)  TX bytes:20573951 (19.6 MiB)
          Interrupt:4

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wifi0     Link encap:UNSPEC  HWaddr 00-0F-B5-3F-21-3C-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5385635 errors:0 dropped:0 overruns:0 frame:904487
          TX packets:134151 errors:237 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:199
          RX bytes:426439102 (406.6 MiB)  TX bytes:13250686 (12.6 MiB)
          Interrupt:2 Memory:c0060000-c0070000

$ iwconfig ath0
ath0      IEEE 802.11g  ESSID:"olsr.freifunk.net"
          Mode:Ad-Hoc  Frequency:2.412GHz  Cell: 02:0F:B5:3F:21:3C
          Bit Rate:0kb/s   Tx-Power:20 dBm   Sensitivity=0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off
          Link Quality:8/0  Signal level:-87 dBm  Noise level:-95 dBm
          Rx invalid nwid:1316  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

10/20/06 23:32:38 changed by jal2@gmx.de

The crash is caused by a KASSERT in net80211/ieee80211_proto.c, line 1365, which assumes, that an IBSS cannot move into state AUTH. Meanwhile in net80211/ieee80211_input.c, line 1288, allows it for an IBSS. The 802.11-1999 standard mentions authentication for IBSS in chapter 5.7.6. Althrough I can rarely see any reason for a IBSS to do so, we should follow the standard.

I'll attach a small patch allowing authentication in IBSS for version 0.9.2. Mathias, could you please test it? BTW, why do you call the packet malicious? What does address1 of an AUTH frame contain?

10/20/06 23:34:16 changed by jal2@gmx.de

  • attachment madwifi_ibss_auth_frame_crash.patch added.

Fixes a crash when an IBSS node receives an AUTH frame. Signed-off-by: Joerg Albert <jal2@gmx.de>

10/20/06 23:57:28 changed by jal2@gmx.de

Looks like ieee80211_input() in ieee80211_input.c, line 297 ff., doesn't care for address1 of MGMT frames received by an IBSS node. Do we miss a check here?

10/22/06 17:06:40 changed by mrenzmann

  • patch_attached set to 1.

10/24/06 10:05:20 changed by kurth@informatik.hu-berlin.de

We call the packet malicious because the first address of the wifi header does not contain a valid mac address but the bssid of the ad-hoc network. It were not sure whether this could be the reason for the crash. But it seemed there was another reason, so you may simply ignore it. Test is in progress.

10/25/06 23:26:09 changed by jal2@gmx.de

Hi Mathias,

what is valid content for the "address 1" field of an AUTH frame send towards an IBSS?

11/03/06 13:34:28 changed by kurth@informatik.hu-berlin.de

The patch works, the node with does not crash any more. I'm not sure but i think the first address should always contain the address of the node the frame is sent to since it is the receiver address.

11/03/06 13:36:33 changed by mrenzmann

  • milestone set to version 0.9.3.

11/22/06 10:03:54 changed by kelmo

  • status changed from new to closed.
  • resolution set to fixed.

Applied to r1818

01/18/07 03:48:49 changed by someone@berkeley.edu

I was getting crashes when trying to use the Ad-Hoc mode. They seemed to be caused by packets coming from a "malicious" WinXP system. Here's part of the backtrace: 

 ath_mgtstart+0xcd/0x210 [ath_pci]
 current_tick_length+0x6/0x40
 ath_rx_tasklet+0x441/0x820 [ath_pci]
 tasklet_action+0x30/0x60
 __do_softirq+0x42/0xa0
 do_softirq+0x26/0x30
 irq_exit+0x35/0x40
 do_IRQ+0x33/0x70
 apm_bios_call_simple+0x88/0xf0
 common_interrupt+0x1a/0x20
 default_idle+0x31/0x60
 apm_cpu_idle+0x1b5/0x270
 cpu_idle+0x41/0x70
 start_kernel+0x27e/0x330
 unknown_bootoption+0x0/0x270

Any ideas if this is the same bug?

01/18/07 03:50:14 changed by someone@berkeley.edu

  • attachment trace.jpg added.

screenshot of the crash

01/19/07 09:33:02 changed by anonymous

I think this may something else, in our case the panic occured in ieee80211_newstate in a kind of assert. The attached patch fixed the problem. So if it also happens with the patch (as I suppose) you know it for sure.

Add/Change #880 (malicious ad-hoc auth frame crashes the system)