From: TINNES Julien RD-MAPS-ISS (julien.tinnesfrancetelecom.com)
Date: Thu Dec 07 2006 - 12:48:00 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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
Dailydavelists.immunitysec.com
http://lists.immunitysec.com/mailman/listinfo/dailydave

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]