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.

Re:So...

[masklinn]

Yeah. In third party drivers for a third-party wireless adapter. He still hasn't disclosed any information on a bug in apple-supplied wireless drivers for apple-supported wireless devices, even though he was offered stuff for actually proving what he'd said (John Gruber, for example, offered to give him two brand-new fresh-out-of-the-box macbooks if he managed to hack them)

Re:So...

[dfghjk]

Still sensitive are you? The claim was that many platforms were vulnerable, not just macs.

"He still hasn't disclosed any information on a bug in apple-supplied wireless drivers for apple-supported wireless devices..."

Nor are they obligated to. Odds are that the presentation had the desired effect and there was no need to proceed further.

"...even though he was offered stuff for actually proving what he'd said (John Gruber, for example, offered to give him two brand-new fresh-out-of-the-box macbooks if he managed to hack them)"

No, here's the link:

http://daringfireball.net/2006/09/open_challenge

Gruber challenged them to hack a macbook (not two) with many stipulations. The challenge was to be videotaped and the conditioned were not under the control of the hackers. If the challenge was not met, the hackers would have to pay for the machine. The results of the videotaping were the property of John Gruber.

There are plenty of reasons for not accepting the challenge. They may have felt that there would be too much risk that they didn't want to accept, they may have not given a shit about John Gruber (likely), they may not have wanted to contributed to his pro-Apple site, or they may have had no interest in the lame reward offered. A macbook may be exciting to you and John Gruber but probably not to them.

Just because additional details were not provided on demand to Apple loyalists does not mean that vulnerabilities didn't exist. IMO the test configuration was chosen because it was the easiest one to demonstrate the flaw. That doesn't mean it's the only one that contains the flaw though Apple apologists have always insisted otherwise.

Re:So...

[node 3]

You can delude yourself all you want.

In what way am I deluding myself? In every conceivable way, the hackers in question have failed to give me any reason to believe they actually had an exploit against Apple's AirPort drivers.

Sure, it's *possible* they really had an exploit, and they just don't care if anyone believes them. But given they've not given me a reason to believe them, why on earth should I?

Even worse, they've never even made it clear EXACTLY WHAT their claim is. In other words, they've never stated, clearly, that they actually had a working exploit against Apple's AirPort drivers.

What makes you want to so strongly defend such an ambiguous claim that has such little evidence?

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:But which OS!?

[Anonymous Coward]

I read the summary just a few seconds after it was posted, and you can imagine the effect it had on me to read this on a laptop using EXACTLY that card, in a wave phyiscs lecture...

Please never scare me again like this, for a moment i thought Windows was more secure than Linux...

Kind of makes me glad I've got homeplug..

[Channard]

I was tempted by wireless, but given I don't have a laptop, I grabbed a couple of these twenty quid each Homeplug devices which plug into a mains socket and send data around the house's main circuit. It not be as 'go anywhere' as Wireless, but in the light of this I guess it's more secure.

Broadcom neglegance

[Anonymous Coward]

They either 1) dont run static analysers or 2) run them but punted the bug

Which is it Broadcom? Either way it is neglegance. Im tired of developers spouting hot air about being Accountable, Responsible and Reliable etc blah blah and especially practicing good engineering and hearing design patterns yawn. I hear it every day, I worked as a dev and left it as its the same old shit every day day in day out, same for test.

We have tools, run them, we have practices, use them.

If those are not good enough, retool and reorg.

Oh wait, its business not engineering, sorry my bad :)

Engineering is a blue collar job today, it should not be called "science" it is not science. Wise up.

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

[cheater512]

I think I've seen the driver in the list.
Dont quote me. I dont have a Broadcom wireless.

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

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.

Re:NDISWrapper

[Carewolf]

There is such a driver in the most recent Linux kernels, but it still uses firmware extracted from Broadcom Windows drivers. So if the bug is in the firmware, it could even affect broadcom native linux drivers.

"BCMWL5.SYS"

[The Creator]

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

Re:"BCMWL5.SYS"

[Wonko the Sane]

The bcm43xx driver included in the kernel can not function without the firmware contained within bcmwl5.sys. So there isn't any way to determine (from this particular article) if the bug affects linux or not.

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?

It has to be said...

[Anonymous Coward]

As the number of cases of these driver-flaw attacks mounts, I think it is fair to say the OpenBSD stance on proprietary driver 'blobs' has been fully vindicated. When they took this stance, a fair number of Slashdot posters were publically knocking them as unrealistic-paranoid-idealists. Well here you have it -- deep-fried crow ... yum.

Re:Will this help?

[enosys]

I'm not sure it's especially hard to write a secure wireless driver. It's more probable that they just didn't think very much about security when writing drivers.

It works because it's free and it can, Re:Linux

[twitter]

Does my "reverse engineered" linux driver have this bug?

Probably not. If it does, it will be fixed soon.

Why is it that a bunch of people who don't get paid come up with bug-free solutions?

It gets fixed because it's free and therefore it can be. Non free software writers put up with NDA's and code they can't share even if they wanted to. Their code is owned and so their effort and good will is likewise owned. Free software writers are free to share their tools as well as their improvements, so it's much easier to help your friends.

By the way, there's no law against being paid to write free software. With all the tools available, free software writers can get the job done faster and for less money. That's something worth paying for and many people do. The vast majority of software jobs are in house, so GPL distribution conditions never take effect and are not an issue. It would be better to share the work with others if you can, but you don't have to and often can't under those circumstances and there is therefore no difference at all between your choice of tools besides the lower cost of the free tools.

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.

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 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 , (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.