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

Thanks

[SnowZero (92219)]

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

Re:NDISWrapper

[by 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:

[cheater512 (783349)]

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.

Re:NDISWrapper

[ettlz (639203)]

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:

[ydrol (626558)]

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 an

Re:

[blackest_k (761565)]

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

Re:

[Carewolf (581105)]

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 (4611)]

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

Re:

[Wonko the Sane (25252)]

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.

Re:

[mjg59 (864833)]

If the bug's in the firmware, it would be very difficult to exploit it to run code in the kernel. Not impossible, but very difficult. The description of the bug makes it sound extremely like the problem is in the driver, not the firmware.

Well crap.

[Merc248 (1026032)]

Checklist for today:

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

So...

[radu.stanca (857153)]

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

Re:

[masklinn (823351)]

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 (711126)]

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 [daringfireball.net]

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:

[node 3 (115640)]

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 st

But which OS!?

[Idaho (12907)]

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:

[by 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 (693317)]

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.

Re:

[Jacco de Leeuw (4646)]

I saw some powerline adapters with 56-bit DES encryption. That's not terribly secure. Your security is mostly based on the fact that the bad guys cannot plug into your mains. Which is probably good enough for home use.

Re:

[Psiren (6145)]

How do these things work on different ring mains? Given that the first floor of my house is on a different ring main (not unusual obviously) to the ground floor, how would I be able to communicate between them? The fusebox is the only place they come together. Can the RF make the jump between them?

Re:

[Channard (693317)]

I've got two circuits, and it works fine. If you have two different meters it won't work, but I can turn my upstairs circuit and downstairs circuit off separately and there's no problem there.

Re:

[Svartalf (2997)]

Fusebox is one place. Power meter's the other. I suspect that most PLC implementations
for home have relied on the meter to handle the cross-over between phases, etc. If you've
got two meters, I suspect you'd need a bridge of some type like the X10 booster bridge for
homes to bridge them all without mixing the power from each feed.

Re:

[Psiren (6145)]

Good point, hadn't thought about the meter. Thanks :)

Re:

[inio (26835)]

Do you have stairs in your house?

Re:

[Svartalf (2997)]

In fact, I do. But relying on HomePlug to "protect you" much better than WiFi
is a little bit of folly. No, you can't have the article's attack made on you.
But as the parent poster has pointed out, you're not as protected as you think-
someone can snoop in on your traffic if they've got their own home plug and can
tap into either phase of the two-phase 220v circuit comng into your house.
With clever enough hardware they wouldn't even need to do that- it emits enough
RF-like signal...

Fixed wiring Ethernet is pr

What about those phone-home laptops?

[IchBinEinPenguin (589252)]

You know, the ones that supposedly 'home home' using any available channel in case they're stolen.
The feature is supposed to be impossible to turn off (for obvious reasons).

How long before someone finds a bug ion one of those? Won't that be fun, a vulnerability you cannot turn off :-)

Broadcom neglegance

[by 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, retoo

User space device drivers

[camcorder (759720)]

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.

Will this help?

[leehwtsohg (618675)]

It seems that the user who controls the wireless card will have access to the wireless card, and thus in this case you could potentially have a wireless virus.

In some cases it could be that the user would have access to all network cards, which would mean that from a virus/spam sending/worm point of view the computer will be usefull to the hacker, even if it is otherwise secure.

Maybe keyloggers will be prevented, and writing to the disc, i.e. malware surviving the next reboot. But in general it seems to me

Re:

[enosys (705759)]

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.

Re:

[TCM (130219)]

Congratulations, you just reinvented microkernels (poorly).

More details at...

[Wanker (17907)]

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]

Separate stack

[QuickFox (311231)]

Why do compilers put buffers on the subroutine-and-return stack? Why not have the compiler use a separate stack for composite data such as buffers, arrays, variable-size data, and all similar stuff, whenever the programmer puts such data on the stack? Wouldn't that stop stack-based code injection?

The added cost in processing time should be quite negligile, as long as simple, fixed-size data, such as integers, are still on the main stack.

Re:

[miu (626917)]

This would make variable argument lists a real nightmare, this wouldn't just be a fire and forget change to the compiler.

Re:

[QuickFox (311231)]

Where's the complication? If you define simple, clear rules about what goes where, this has the same complexity as keeping track of the sizes of integers, floats etc, something compilers do all the time.

Depending on various considerations you might define, for example, that integers, floats, chars, booleans and pointers go on the main stack, along with all data types that have been defined to be implemented as these types. Everything else goes on the second stack. Thus, for example, all arrays go on the sec

Re:

[QuickFox (311231)]

The second stack could be a special part of the heap space. What I mean here is the space where you get memory when you issue memory-allocation calls.

There would be a special part of heap space that would grow and shrink as a stack. This special area could be very similar to the ordinary heap, with the difference that allocation and deallocation is very much faster, since it grows and shrinks as a stack.

With this arrangement, dynamically linked modules don't necessarily need to be aware of the second stack.

It's a design decision...

[Svartalf (2997)]

In reality, C's behavior (and a lot of other languages, really) are governed by behaviors within the CPU hardware
they were originally intended for. In the case of C, the machines in question only had one hardware stack, so they
intermingled the subroutine return state with the parameters, etc. for speed's sake. Implementing a second stack
in software would have been problematic because it would have added extra performance issues and ate into the
register store (you want to probably reserve a register for th

Workaround for non-Linksys devices

[Jacco de Leeuw (4646)]

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.

Please stop using C.

[master_p (608214)]

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

(and please I do not want to hear 'but Linux is so safe', because it is not).

Link to previous post:

http://it.slashdot.org/comments.pl?sid=204783&cid= 16723899 [slashdot.org]

Re:Please stop using C.

[FireFury03 (653718)]

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 (71693)]

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:Please stop using C. - Duh

[mustafap (452510)]

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

Thats like saying guns kill people.

Stupid people are the problem, not the tools.

Re:

[Beryllium Sphere(tm) (193358)]

You don't have to be stupid to screw up in C, that's the problem. The only way to be safe is to write your own string handling functions and ban all others, in which case you've changed the language: you've made it so fascist that it's not-C.

Re:

[ettlz (639203)]

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

I'd like to see you try this out on the OpenBSD mailing list.

It has to be said...

[by 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.

buffer overflows...

[hitmark (640295)]

why is it that these keep being the single biggest remote security problem?

Re:

[Beryllium Sphere(tm) (193358)]

'cause heap overflows are harder to exploit?

Are they even the biggest remote security problem these days, with cross-site scripting and SQL injection running rampant?

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

[twitter (104583)]

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'

Re:

[Proud like a god (656928)]

Less assumptions made about how the thing works? Trial and error should still find the rare conditions that might be stated in such a manual, and also find those that are not.

Re:

[Svartalf (2997)]

Probably at least a DoS attack will be possible since the vector of attack is through
the firmware layer for the device.