Code Execution Bug In Broadcom Wi-Fi Driver 157
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."
So... (Score:4, Insightful)
Broadcom neglegance (Score:2, Insightful)
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.
User space device drivers (Score:5, Insightful)
Re:Broadcom neglegance (Score:1, Insightful)
More fool them. Its pure and simply, bad engineering, product design and management.
Re:Please stop using C. (Score:5, Insightful)
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... (Score:2, Insightful)
Re:Will this help? (Score:2, Insightful)
Re:So... (Score:3, Insightful)
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?