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]

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

[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]

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]

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:

[Mathinker]

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

Out of the table of ten global "chip family id's" listed here [berlios.de], only 3 are currently listed as supported, the others are at best "unstable".

And personally, I didn't manage to get a BCM4318 "Air Force One"-based card (no, I didn't buy it, it was "inherited") working with the native module (Ubuntu Dapper). Sigh. Guess it's time to fish out the long cables until the Windows drivers get patched.

Re:

[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

Re:

[flydpnkrtn]

The FreeBSD equivalent of NDISwrapper is "Project Evil" [pingwales.co.uk] if anyone's wondering...

The bcm43xx driver doesn't work

[Viol8]

At least not for my HP pavilion laptop. I have to use ndiswrapper.

Re:

[LordWoody]

I have a one-year-old HP zd8000 (17" model w/P4) and the bcm43xx works fine for me. It also works on our two-year-old zd7000 models.

Re:

[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 an

Re:

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

Re:

[Carewolf]

No. There is a new one for broadcom wireless. It's called bcm43xx

Re:

[ncc74656]

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.

There is a native driver [berlios.de], but neither it nor ndiswrapper work worth a damn with my AMD64 Gentoo install. For the time being, I've given up on getting Linux WiFi working and just hang a Linksys WTR54GS [linksys.com] off the network jack when I need to connect to someone's wireless network.

"BCMWL5.SYS"

[The Creator]

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

Re:

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

Re:

[mjg59]

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.

Zonk only uses Windows and Hates SONY

[Mongoose]

You get it now? You have to read using the 'editor' name as context. =)

ndiswrapper

[Alban]

Is the threat still in effect if the broadcom driver is used under linux with ndiswrapper?

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:

[Gideon Fubar]

It pissed me off at the time that so many people were jumping on the anti-anti-apple bandwagon, without knowing John's credentials.

It was never about apple, kids. That's what he (and guys like him) do. Just be greatful he's on your side, not just his own.

Re:

[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 [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]

There are plenty of reasons for not accepting the challenge.

The primary reason being that they couldn't do it.

Their problem is that they made ambiguous claims, and were given many chances to clarify their claims. Specifically, do they have a working exploit that can take over a clean, up-to-date MacBook with no user-intervention other than that the AirPort card be enabled? They've never directly answered that question. NEVER. And they've been given multiple opportunities. Gruber's challenge was mean to fina

Re:

[dfghjk]

"The primary reason being that they couldn't do it."

Only they know the answer to that, not you. I figure they don't consider themselves circus animals and don't have any interest in jumping through hoops on orders from a clown like Gruber. It's also conceivable that they may have had some sort of agreement in place that restricted what they could publicly disclose.

"Their problem is that they made ambiguous claims, and were given many chances to clarify their claims."

Who gave them these chances? Anyone th

Re:

[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 st

Re:

[dfghjk]

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

In every conceivable way? The fact that they demonstrated the flaw and said it existed in many configurations including Apple's isn't conceivable to you? You live in a fantasy land where Apple can do no wrong.

"But given they've not given me a reason to believe them, why on earth should I?"

They did give you a reason to believe them but you chose do de

Re:

[node 3]

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

I don't.

Yes, you do. You're doing it right now.

You live in a fantasy land where Apple can do no wrong.

Straw man, I've stated nothing of the kind.

Funny that Apple released updates shortly after their demonstation however.

Gee, with all the attention on the drivers, funny that Apple would go through and look at them! However, the update *DOESN'T ADDRESS THE SAME ISSUE IN QUESTION*. Funny that doesn't seem to matte

Re:

[dfghjk]

"Yes, you do. You're doing it right now."

I have not. All I've done is consistently counter the claims by you and others that the researchers were frauds who failed to support the claims of flaws on the mac platform. I've never defended them other than to support that that could have been right and I've offered reasons to explain non-response to public criticism. It is you that is making indefensible claims here, not me. I have no position one way or another on their claims other than I take them at face

Re:

[masklinn]

So you'd prefer total disclosure so that someone can write a tool any kiddie can use to gain kernel mode access to your machine?

Or so that the company involved can and has to update it's flawed drivers and patch the flaws.

Yes.

Re:

[dfghjk]

Who says they didn't? Full *public* disclosure isn't necessary for that. Considering that Apple did, in fact, update their products shortly afterward suggests that there was sufficient disclosure for that to happen.

Re:

[dfghjk]

John Gruber is a grandstander who attempted to turn the spotlight onto him. His offer couldn't possibly match what the researchers hoped to gain (and most certainly did gain) through consulting on the issue. There were reasons why the researchers presented the flaw and chief among then certainly wasn't to increase attention for an Apple cheerleader's blog. Odds are that they wanted to get paid (and I don't mean with a single MacBook).

Re:

[masklinn]

Still sensitive are you?

Not really, I don't even own a laptop let alone a mac.

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

So you acknowledge that it was a stunt and a lie. Good.

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.

Uh yeah? His conditions seemed pretty standard stuff it you look at it fro

Re:

[dfghjk]

"So you acknowledge that it was a stunt and a lie. Good."

I acknowledge that what you just said was a stunt and a lie.

"Uh yeah? His conditions seemed pretty standard stuff it you look at it from a scientific standpoint."

Sure, videotaping and having the camera controlled by john gruber is part of the scientific standpoint. I'm sure that offered plenty of encouragement. Offering a measly reward worth, at best, a small fraction of what they could have gotten from Apple, was part of the scientific standpoint

Re:

[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 privi

Re:

[masklinn]

If their hypothetic flaw is now patched, why don't they demonstrate their attack on an unpatched macbook unless "because they didn't find a flaw in the first place"?

You know, scientific method 101 says it's not ours to disprove that they found a flaw, it's theirs to prove they found one in the first place, which they've never done.

Re:

[dfghjk]

"If their hypothetic flaw is now patched, why don't they demonstrate their attack on an unpatched macbook unless "because they didn't find a flaw in the first place"?"

There you go proclaiming the reasons for things you don't understand. Who says they haven't demonstrated it? They just haven't demonstrated it to you.

"You know, scientific method 101 says it's not ours to disprove that they found a flaw, it's theirs to prove they found one in the first place, which they've never done."

The scientific method s

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:

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

Johnny Cache

[davro]

Quote
"Microsoft's Windows operating system is exploitable without the existence of an access point or any interaction from the user.
The card's background scan of available wireless networks triggers the flaw," the group said.
eWEEK.com Special Report: Mac Security"

The bug was first discovered by wireless security guru Jon "Johnny Cache" Ellch, the researcher who was embroiled in a controversy with Apple over similar bugs in the Wi-Fi driver that ships with the Mac OS X.


Checklist for today:

1. Ea

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.

Re:

[UncleTogie]

{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.}

Does your house have any external outlets? ;)

Re:

[inio]

Do you have stairs in your house?

Re:

[Svartalf]

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

Re:

[Jacco de Leeuw]

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]

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]

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]

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]

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

What about those phone-home laptops?

[IchBinEinPenguin]

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

[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

Re:

[Anonymous Coward]

They probably don't even Thread Model their products or run injectors and fuzzers.

More fool them. Its pure and simply, bad engineering, product design and management.

Linux

[utopicillusion]

Does my "reverse engineered" linux driver have this bug. I guess not. Why is it that a bunch of people who don't get paid come up with bug-free solutions? I guess, either they love their job very very much, or its just the development philosophy or both :)

Re:

[cheater512]

Well they are doing it for free and in their spare time so I think they would actually *care* about it.
Plus they are generally better than the Broadcom devs because they dont have the chip manual infront of them while they are writing the driver.

Re:

[Proud like a god]

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:

[oesj]

...or people spend(waste) less time looking for their bugs?

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'

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.

Will this help?

[leehwtsohg]

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]

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]

Congratulations, you just reinvented microkernels (poorly).

Is this related to the

[porkchop_d_clown]

allegedly mythical (No it's not!) (Yes it is!) (No it's not!) Airport exploit for Macs?

I still haven't been able to figure out if they've demonstrated a real vulnerability or not...

Re:

[camperslo]

allegedly mythical (No it's not!) (Yes it is!) (No it's not!) Airport exploit for Macs?

I believe there is a strong possibility it is related. I've used a third-party wireless card with a Broadcom chipset in G3/G4 Macs before, and it was recognized as an Airport Extreme (b/g) card.

I've heard that Broadcom has been less than cooperative in providing specs for others to write drivers. Perhaps if they were more open they'd have a better scrutinized more secure product. (I can't provide specific links, but I

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]

Separate stack

[QuickFox]

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]

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

Re:

[QuickFox]

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]

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.

Re:

[QuickFox]

Stack-smashing attacks are not the only sort of exploit.

Indeed. But I think that, among those exploits that have really severe consequences, this is one of the most frequent.

It's a design decision...

[Svartalf]

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

Re:

[QuickFox]

Do modern processors have such a small number of registers? I haven't looked at processors for quite a while, the last processor I knew well was the Motorola 68000. That one had eight address registers and eight data registers. In that one you could easily have spared one address register for a second data stack. Do modern x86 processors have so much fewer suitable registers?

(I wish the PC had been based on the MC68000 architecture, it was so much better in so many ways!)

Re:

[hughk]

If memory serves me right, C first came about on a PDP-11. You had a program counter, PC or R7, the main stack, SP or R6. You also had five other general purpose registers (but you could do arithmetic on R6 and R7 as well), and the instruction set being nicely orthogonal, although the return address always went on the stack, any register could be used as the argument list pointer. Note that towards the end of life, the later 11s even implemented seperate I and D spaces which made it impossible to stick code

Re:

[TheRaven64]

Dovecot, the POP/IMAP server developed by one of the OpenBSD guys, uses this kind of system. At the library level, it has a separate data stack. Allocations on the data stack are cheap (because you just increment a pointer, rather than doing messy things with the heap), and the data stack can be pushed and popped independently of the control stack. This has some nice features like a sprintf analogue that allocates its own space on the data stack, but then doesn't pop it on return, so you don't need to wo

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:

[kahunak]

You can also replace the bcmwl5.sys file, usually located at C:\WINDOWS\SYSTEM32\DRIVERS with the one provided by linksys, just download linksys drivers from here [linksys.com] , extract them, disable your network adapter, copy the new bcmwl5.sys (make a backup of your own bcmwl5.sys just in case...) and activate the card again. It is a temporary solution but it's better than nothing and you don't change the name of your network card. Tested on a Dell MiniPCI 1300 WLAN and it works.

bcm43xx

[Jack Malmostoso]

How does this affect the native bcm43xx linux driver, since the original firmware is used?
Thanks for any explanation.

Re:

[Svartalf]

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

Yawn

[dangitman]

I guess "Johnny Cache" got tired of trolling for media coverage about his non-existent MacOS wireless exploit, and decided to publish the less sensational information about the OS and systems that it actually affects. So, instead of being a big bad boy who rocks the world by pwning Macs, it's just one more of thousands of boring Windows exploits.

By the way, what is this guy's name? I've seen it published as "Erlich" and "Elich" before, and now slashdot says it's Ellch. One thing's for certain. Anybody who c

Please stop using C.

[master_p]

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]

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

[Viol8]

"Provably correct operating system design is not a theory, but no one seems to be interested."

Possibly it has something to do with formal proofs only being realistic on toy systems.
Anyone can formally prove a 1 line Hello World program will work to spec but try
to formally prove the 20 odd million lines of code in a modern OS and your descendents
will still be doing it 3 generations from now.

Re:

[master_p]

I do not see how bounds checking can really affect performance of a Wi-Fi driver. It is not that we are talking about something that getting 0.1% speedup is crucial.

But since you asked, there are two solutions:

1) use Cyclone. It outputs C code anyway, and the language provides enough mechanisms to identify where it does not need to do bounds checking.

2) use Ada. It also outputs C code, and its range types are a good solution to the problem.

3) use C++ as C on steroids: simple template value classes for array

Re:

[Viol8]

"However, I don't think a wireless driver falls into this category."

So you don't think data throughput speed is important then?

Re:Please stop using C. - Duh

[mustafap]

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

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:

[mustafap]

Higher level tools might be great for the kids of today, writing social web sites.

The kids of today however don't have a clue about the programs on which this internet is based on. The routers, the switches, the firewalls. Do you thing they are all written in C++ or Java?

C powers this world. You just don't know it.

Re:

[ettlz]

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.

What about ndiswrapper and bcm43xx kernel driver?

[kahunak]

Are they affected? Ndiswrapper directly uses routines from BCMWL5.SYS so I suppose it is also affected and the bcm43xx module needs the firmware from it so maybe it is also affected. Any idea??

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:

[Andy Dodd]

Where are my mod points when I need them.

With the exception of the Atheros HAL (which, while semi-closed, has a decent number of people outside of Atheros looking at it - Most of the Atheros HAL ports are done by non-Atheros volunteers who have signed NDAs for the source), pretty much all other binary "blobs" only execute on the card itself. Whether the blob has a bug or not, as long as the code interfacing with the card that runs as part of the OS kernel itself is open-source and secure, a firmware blob t

buffer overflows...

[hitmark]

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

Re:

[Beryllium Sphere(tm)]

'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?

Re:

[hitmark]

i would say so because they hit not only web servers but potentially every computer out there thats connected to the net and running the problematic code.

Re:

[TheRaven64]

No idea. OpenBSD has been immune to most of this kind of vulnerability for ages (they can cause crashes, but not compromises). They use a variety of techniques, including a variable size gap between stack frames (making it very difficult for an attacker to put the jump in the right place) and a canary value next to the return address (so that a modified canary shows that the return value is broken).

I believe some of these changes have made their way into the main branch of GCC, although I don't think a

Re:

[hitmark]

hmm, that reminds me that supposedly there is some memory address randomization stuff in vista.

and isn't there supposedly something similar in linux to?

heh, maybe i should consider going openbsd (heh, nice name for such a secure bsd).

hell, why i have yet to go linux atleast i don't know...

Someone please enlighten me...

[93 Escort Wagon]

Their day one bug was an exploit of the old Apple Airport - Broadcom - wireless drivers. This day eleven exploit is of Broadcom's Windows wireless drivers. I realize the OS has changed, but is this more or less the same exploit? Or is this leveraging some issue that's actually in the chipset?

Re:

[93 Escort Wagon]

Man that's what I get for posting before I've had my coffee. The old Apple wireless was Orinoco - the newer chipset is Broadcom. Should've been blindingly obvious this is related to the Johnny Cache dog and pony show, I guess.

I'll go make a pot before I come back.

Re:

[wolrahnaes]

The cards in the Intel Macs (at least the Macbook and MBP) are Atheros, not Broadcom. IIRC the 24" iMac has a Broadcom Pre-N card, but the rest are Atheros.

What Century Will It Be

[Master of Transhuman]

...when programmers FINALLY learn to stop producing buffer overflow conditions?

How many years now have they known this is a no-no?

When the hell are programmers going to be adequately trained in proper coding procedures?

When the hell are humans going to stop taking pointless shortcuts contradictory to their end goals? Or start using computers to CHECK FOR their stupid mistakes instead of using them to MAKE their stupid mistakes?

I've just switched back to Opera 9 because Firefox 2.0 is so riddled with stupid