Madwifi SIOCSIWSCAN vulnerability (CVE-2006-6332)

[TINNES Julien RD-MAPS-ISS <julien.tinnes () francetelecom com>]

There is a kernel stack buffer overflow in Madwifi SIOCSIWSCAN ioctl
which is used to list scanned AP.

All version prior to 0.9.2.1 are probably vulnerable.

Users listing nearby access points (such as with "iwlist ath0 scan")
manually are at risk. As a lot of distributions are performing automatic
access point listings, this can put passive users at risk as well.

We wrote a remote DoS as well as a reliable local privilege escalation
exploit (which needs to be triggered by the remote DoS).
As the impact is not very critical (you have to be able to execute code
on the host AND to send a wireless packet), they will be released soon
as proof of concept.

A real remote exploit is very likely to be possible, against iwlist or
any other process using this ioctl (being in process context helps!),
however we've not investigated it further for now.

PS: Dave, will we have Wifi support in Canvas ?

-- 
Julien TINNES - & france telecom - R&D Division/MAPS/NSS
Research Engineer - Internet/Intranet Security
GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6

Name:           Madwifi < 0.9.2.1 remote buffer overflow vulnerability
Vendor:         http://www.madwifi.org
Release date:   December, 7th 2006
CVE ID:         CVE-2006-6332
Authors:        Laurent BUTTI, Jerome RAZNIEWSKI, Julien TINNES


1. Description

There  is a  buffer  overflow  in the  madwifi  Atheros  driver in  some
functions called by SIOCSIWSCAN ioctl.

This  issue is  remotely exploitable  because ioctl  SIOCSIWSCAN may  be
called  automatically by  some connexion  managers (either  directly, by
using iwlib or  by calling iwlist) when  trying to get a  list of nearby
access points.

2. Details

There is  a stack buffer  overflow in both giwscan_cb()  and encode_ie()
Thefunctions  (ieee80211_wireless.c).  first  issue, in  giwscan_cb,  is
Therelated  with  insufficient  checks  on the  length  in  some  802.11
Theinformation elements which are controlled by the attacker:

        memcpy(buf, se->se_wpa_ie, se->se_wpa_ie[1] + 2);

The second issue is improper  boundary checks in encode_ie() where ielen
is never checked with bufsize.

        for (i = 0; i < ielen && bufsize > 2; i++)
                p += sprintf(p, "%02x", ie[i]);

A properly  crafted 802.11 beacon  or probe response frame  will trigger
the bug  when a process tries  to get scanning results  by calling ioctl
SIOCGIWSCAN. The information element used  by the attacker can be either
WPA  IE, RSN  IE, WMM  IE or  ATH IE  and will  lead to  a kernel  stack
overflow.

3. Vendor status

The vendor was notified on December, 6th 2006 and issued version 0.9.2.1
to correct the issue.

4. Authors

Laurent BUTTI <laurent.butti at francetelecom.com>
Jerome RAZNIEWSKI <jerome.razniewski at francetelecom.com>
Julien TINNES <julien.tinnes at francetelecom.com>

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://lists.immunitysec.com/mailman/listinfo/dailydave