LWN.net Logo

MadWifi: Much ado about nothing?

April 18, 2007

This article was contributed by Jake Edge.

A recent article reporting a remotely exploitable bug 'in Linux' has raised the ire of some in the Linux community for a few reasons, but inaccuracy probably tops the list. The timeliness of the report is also in question as the bug, in an out-of-tree Linux driver, was fixed four months ago in December 2006. When the usual suspects, Slashdot and digg, linked to the article, it became a rather visible 'failing' of Linux. The truth is much less damning; there are some interesting wrinkles, though, which are worth a look.

The bug was found by French security researchers when fuzzing the MadWifi driver for Atheros Wireless LAN chipsets and was presented at Black Hat Europe at the end of March. The techniques used are similar to those used by David Maynor and johnny cache to find the MacOS wireless flaws that they 'demonstrated' at Black Hat USA last year. The only new information in the article (and others like it) was the presentation given by Laurent Butti; the bug had already been reported as CVE-2006-6332 and fixed in version 0.9.2.1 of MadWifi.

MadWifi (which is an abbreviation for Multiband Atheros Driver for Wireless Fidelity according to the project's website) is a widely used driver for wireless cards, but it is not part of the Linux kernel and is unlikely to ever be. The driver relies on a 'Hardware Abstraction Layer' (HAL) that is only provided in binary form. The belief is that because the Atheros chips can be instructed to do various things that regulatory agencies (the FCC in the US for example) oppose, the code for doing that must be closed source. Rather than make the whole driver closed source, separating it into two pieces was done specifically to avoid the closed source portion being considered a derivative work of the kernel.

Because of the non-firmware binary blob, the driver will not be included in some 'free' distributions and users will need to find it from other non-official or less supported repositories. This could lead some users to not update their driver because the package management system did not alert them to the change. At some level, any publicity that makes more people aware of the problem is probably a good thing.

The bug itself is a fairly run-of-the-mill buffer overflow that is fixed in this changeset. While the bug was rather straightforward, its result is catastrophically bad. An attacker could run arbitrary code as root on a vulnerable machine that has the driver loaded; being connected to a wireless network is not required. This is the kind of 'drive by' laptop takeover that got so much attention when Maynor and cache announced their proof of concept exploit. It is a truly horrifying scenario for anyone worried about laptop or other wireless device security.

At the time of the original release of information about the bug, the MadWifi project and various distributions made announcements about it. But, perhaps because of the impending Christmas holiday or because the seriousness of the bug was not recognized, there was very little press about it at that time. Though LWN did publish the announcements, one could certainly argue that a more detailed look was in order. Coupled with the severity of any exploit, the lack of coverage magnified the importance of the current articles. Had there already been a round of articles describing the flaw back in December (or even January), it is likely that the 'new' reports would have been ignored.

That does not, of course, excuse the inaccuracies in the article. MadWifi is clearly not 'in' Linux though it will affect some Linux users. The lack of earlier press coverage and linking from aggregation sites served to elevate the visibility of the bug, which may have helped some users who missed it earlier, but overall just fed the 'Linux is buggy' hype machine. The headline and the way it was presented take an interesting event, the presentation of some security research, and try to turn it into an indictment of overall Linux security. This is the kind of article that tends to make Linux advocates rather cynical about the 'mainstream' technical press.


(Log in to post comments)

MadWifi: Much ado about nothing?

Posted Apr 19, 2007 13:53 UTC (Thu) by linville (subscriber, #31482) [Link]

This story, of course, confirms one of the many reasons why binary-only
software is considered dangerous by the Linux developers even in
situations (e.g. userland apps) where licensing is not really an issue.

FWIW, I would _love_ to have a driver for Atheros hardware in the Linux
kernel. But we would never be able to tolerate a closed-source blob
component, even _if_ there were some magic GPL loophole found to allow
it.

MadWifi: Much ado about nothing?

Posted Apr 19, 2007 18:11 UTC (Thu) by thyrsus (subscriber, #21004) [Link]

I run Fedora, and for a while I used an Atheros based WiFi card. The instructions on how to build the driver never matched my distribution, and it would take hours of guessing at how to do the compilation properly to get the thing to work - and then within a few weeks there would be a new kernel out, and if I wanted to update it meant redoing those hours of work. In the end, it wasn't worth my time and I bought a different card. The patience to get an Atheros card working would not be available to the vast majority of Linux users. Does anyone know if folks like Emperor Linux were distributing these binaries? That, and adoption by oraganizaion's sysadmins, are the only ways I can think of that they might have a wide deployment.

Binary Blobs?

Posted Apr 19, 2007 23:31 UTC (Thu) by mrons (subscriber, #1751) [Link]

Could someone explain why the MadWifi driver "will never be allowed in the linux kernel" because of the binary blob, yet the Intel ipw driver is allowed despite the requirement to load a binary blob to make it work?

Binary Blobs?

Posted Apr 20, 2007 0:59 UTC (Fri) by njs (guest, #40338) [Link]

The Intel blob is firmware -- i.e., code loaded onto the card that executes on its processor. The MadWifi HAL is a user-space, closed-source, daemon that must be running for the kernel driver to work. One could argue this is a distinction without a difference, but I believe it's the distinction people have drawn.

Binary Blobs?

Posted Apr 20, 2007 12:14 UTC (Fri) by ewan (subscriber, #5533) [Link]

It's worth noting that there are two versions of the intel ipw3945 driver - one which requires a binary userspace daemon and which was never included in the mainline kernel, though it was in several distributions; and a more recent one that only requires binary firmware to be downloaded to the card, not run on the host processor.

Binary Blobs?

Posted Apr 26, 2007 11:40 UTC (Thu) by quintesse (subscriber, #14569) [Link]

I imagine that the difference is that it is very difficult for code on the card to get root access to your system. So while any ethical problems remain (as RMS would probably point out) the practical situation is very different by making sure that the closed source binary runs in its own "sandbox".

Binary Blobs?

Posted Apr 27, 2007 1:40 UTC (Fri) by pimlottc (guest, #44833) [Link]

Hey, thanks for the pointer on the newer obnoxious proprietary daemon free driver for the Intel
card. I hadn't heard about that. Will try it out.

MadWifi: Much ado about nothing?

Posted Apr 27, 2007 16:22 UTC (Fri) by peschmae (subscriber, #32292) [Link]

Actually the closed-source HAL is not really necessary. One can also run Madwifi with the OpenHAL replacement. See: http://madwifi.org/wiki/OpenHAL

The branch seems to be maintained - at least there were changes in it in april and it compiles and works with the latest kernels (just now running on 2.6.21...)

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds