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."

Comments

Thanks

[SnowZero]

Thanks for mentioning the affected operating system(s). Oh wait, you didn't...
Here, I'll help:
Code Execution Bug in Broadcom Wi-Fi Windows Driver

Well crap.

[Merc248]

Checklist for today:

1. Eat
2. Rant on Slashdot
3. Change SSID from "omgomgomgomgomgomgomg" to "omgomgomg"
4. Sleep

So...

[radu.stanca]

...the BlackHat presentation this Johnny Cache gave was not just FUD, he really did find bugs in wireless drivers.

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?

User space device drivers

[camcorder]

There's a discussion about having user space device drivers for usb wireless sticks and some other drivers as well for linux kernel. I hope this kind of attack vectors encourage kernel developers to go in this way. Keeping stuff in user space as much as it allows would again let Linux to be secure-by-design once again. Currently couple of tools (like wpa_supplicant) running in user space, and I wonder their situation in Windows kernel. If they are not (which I guess they are not -because microsoft is known to be putting huge code into kernel level) then that's a huge problem from security perspective.

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.

"BCMWL5.SYS"

[The Creator]

This is slashdot, you are supposed to guess the OS from the filename of the device driver.

More details at...

[Wanker]

SANS has a concise summary:

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

Or look at the Month of Kernel Bugs site itself:

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

Workaround for non-Linksys devices

[Jacco de Leeuw]

George Ou at ZDNet has published a procedure 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:Please stop using C.

[FireFury03]

C is the source of all these problems. Please stop using it.

It's not that simple. C is used in high performance code specifically because it's fast and compact. You get these improvements by avoiding needless length checking. Obviously there are cases where you _do_ need to length check buffers (and exploits are the result of not doing this), but you don't have to length check everything. If you ditch C in favour of a language that does the length checking for you then you will sacrifice speed and compactness since it will be checking _everything_.

What language would you suggest is more suitable for writing high performance kernel code?

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. Or even use a whole OS 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.