Code Execution Bug In Broadcom Wi-Fi Driver

2U*U2 writes to mention an EWeek article about an entry in the Month of Kernel Bugs. John Ellch has discovered a critical vulnerability in the Broadcom wireless driver: a driver used in machines from HP, Dell, Gateway, and eMachines. From the article: "[The bug] is a stack-based buffer overflow in the Broadcom BCMWL5.SYS wireless device driver that could be exploited by attackers to take complete control of a Wi-Fi-enabled laptop. The vulnerability is caused by improper handling of 802.11 probe responses containing a long SSID field and can lead to arbitrary kernel-mode code execution. The volunteer ZERT (Zero Day Emergency Response Team) warns that the flaw could be exploited wirelessly if a vulnerable machine is within range of the attacker."

But which OS!?

[Idaho]

I mean, it's bad enough that people always talk about "Computer viruses" instead of "Windows viruses" and so on, but come on, can we please include *some* information in the post itself?

Admittedly, the article to which this newspost links also doesn't mention this until the third or fourth paragraph or so.

At first I thought the article was about the Linux kernel, in that case I would have wanted a (global) list of the OS's/versions affected as well, because my laptop might have been vulnerable in that case!

So, I assume it's just Windows XP SP2 (and probably older SP's), or other versions as well?

Re:NDISWrapper

[Anonymous Coward]

Don't forget about people using NDISWrapper, which is the only way to get such cards working on Linux at all unless someone has written a driver recently.

Re:NDISWrapper

[ettlz]

Broadcom users on Linux should really be using the bcm43xx kernel module by now.

Anyway the flaw wouldnt affect Linux systems. Why? Different kernel.

NDISWrapper executes the Windows Kernel Mode NDIS driver in the Linux kernel's address space. So it might still result in code injection. It might even extend to FreeBSD when running bcmwl5.sys under its equivalent as well.

More details at...

[Wanker]

SANS has a concise summary:

http://isc.sans.org/diary.php?storyid=1845&isc=2e0 1b45094b0425b829255e39eb2f8d2 [sans.org]

Or look at the Month of Kernel Bugs site itself:

http://projects.info-pull.com/mokb/MOKB-11-11-2006 .html [info-pull.com]

Workaround for non-Linksys devices

[Jacco de Leeuw]

George Ou at ZDNet has published a procedure [zdnet.com] on how to use the Linksys drivers with devices from other vendors such as Dell and HP. Of course this is not an ideal solution but if it works it's better than nothing.

Re:So...

[tunjin]

i would not be so fast to claim his story false - maybe you should read through the description of this airport update: http://docs.info.apple.com/article.html?artnum=304 420 [apple.com]

...A heap buffer overflow exists in the AirPort wireless driver's handling of scan cache updates. An attacker in local proximity may be able to trigger the overflow by injecting a maliciously-crafted frame into the wireless network. This could lead to a system crash, privilege elevation, or arbitrary code execution with system privileges. This issue affects Intel-based Mac mini, MacBook, and MacBook Pro computers equipped with wireless....

http://roman.studio78.at/ [studio78.at]

Puh-lease.

[Inoshiro]

We've come a long way in the past 30 years in compiler theory and language design. We can do better than C without losing speed [wikipedia.org]. Or even use a whole OS [washington.edu] in a restricted language. You can do compile-time checking of your pointers, as Spin proves.

C is, essentially, portable assembly language. I love it -- it's one of the languages I know the best, and I continue to work in it. However, I'd love to see the use of Cyclone or special compile-time checked languages for the essentials. I think most device drivers could be easily rewritten to be bullet-proof (stack overflow) this way, and such languages are easier to do state machine analysis on (since most device drivers are simple pieces of software that control the state of the hardware). Provably correct operating system design is not a theory, but no one seems to be interested.

Re:NDISWrapper

[blackest_k]

The BCM4318 in native mode ie using the linux driver will only work at reduced speed and transmit power.
currently I think its officially listed as unsupported (11Mbs and 18Dbm)in ubuntu. Using ndiswrapper the driver forces the card from mode0 to mode2 and the card works reliably at 54Mbs and transmits at 25Dbm.
whats mode0 whats mode2 you could ask broadcom but they don't answer. Personally I would boycott Broadcom products and go for a more linux friendly companys chipset such as ralink, unfortunately with laptops its harder to avoid broadcom the wireless is minipci but the bios locks out non hp approved cards however
http://stachon.webpark.cz/ipw-eeprom.html [webpark.cz] might help with that.

Re:NDISWrapper

[ydrol]

Broadcom users on Linux should really be using the bcm43xx kernel module by now.

They want to , but bcm43xx is still unstable in long term use for some chips. It will work happily for a few hours, or even days and then something bad happens (ranging from dropped connections to panics). A lot of people have blacklisted this driver and gone back to Ndiswrapper [google.co.uk] , (eg new installs of Mandriva 2007, Ubuntu 6.06).

I personally had the bcm43xx drivers cause system instability with two very different machines and different broadcom chipsets. Going back to ndis made things stable again.

But Kudos to the bcm43xx developers, I hope they get this cracked. although in the future, I'll make more of an effort to steer clear of Broadcom, both because of their lack of co-operation in supporting Linux AND this recent news.

Broadcom can join Canon on my shit list.