Buffer overflow bug bites Linux wireless component A security flaw involving a wireless driver poses a severe risk for Linux-based systems. The buffer overflow bug in NDISwrapper's Windows Wi-Fi driver kicks in when a long Extended Service Set Identifier (ESSID) is processed. The flaw could be used to crash vulnerable systems. In certain conditions, it might even be possible …
Just to clarify, you only need ndiswrapper if your card drivers are binary only, wrapped up drivers from other operating systems.
Let this be the jump off point for all Linux users doomed to binary-only drivers to shout at their NIC manufacturers (hey Broadcom, we're looking at you especially) to open their specs and let the community code better, more stable drivers, free of charge.
The GPL will create assurances that these drivers could be ported over to the leading brand OS with minimal effort.
This post has been deleted by its author
Buffer overflow. How old is that type of bug? Apparently there are still developers who have no idea that when you manipulate memory buffers, you need to be careful where you put your bits and bytes. With great power comes great responsibility. So when programming with a language like C that allows you to address memory directly, make sure you program responsibly. If you can't be arsed, program in a language that shields you from that type of problems, such as Java or Ruby. Note that I'm not bashing any of those language, I use all of them but with powerful toys, you have to be careful. It's a bit like rm -rf under root: you need to understand how powerful that command is before using it, otherwise it will all end up in tears.
Anyway, why would you use NDISwrapper for Wi-Fi on Linux these days? I haven't come across Wi-Fi hardware that wasn't supported natively for a long time. OK, maybe it's because I haven't bought a brand new cutting edge machine for some time :-)
We need a cowboy icon for that sort of things because that's what they are: programming cowboys. The skull and crossbones will do.
And what, then, if your lappy only recognises the Broadcom card's DevID or, worse, the subvendor ID it shipped with and errors out on POST with anything else in its MiniPCI slot? Hack the BIOS? I hope you're good with checksums. What about the Atheros HAL? I know they've open sourced an older variant of it, but how do we know these binary blobs don't harbour off-by-one errors or unchecked buffer overflows and such? Ralink (2501 and 2600 MIMO. The original 2500 hardware didn't need it) firmware? Intel firmware? The list is endless. Like it or not, there's plenty of scope in the "open source" drivers for such errors to be creeping in and, let's not forget, the bit of NDISwrapper that has the bug IS open source.
Life ain't that simple. Idealism is a fine thing but it's hardly realistic when you have the FCC and other agencies making rules and breathing down vendors' necks and people who aren't technical enough to hack the BIOS on their Thinkpad using this stuff. NDISwrapper and ndisgen make this a lot easier for folks who haven't the time or inclination to lobby hardware manufacturers or get the FCC the back the hell off.
As an aside, I recall when this was called "Project Evil." We now know why.
You mean this wasn't picked up in the pre-alpha-release by the eternal vigilance of the Open Source community, perpetually scanning every line of code with its all-seeing eye and correcting all possible faults before the original coder has even exited vi ?
My entire world view is shaken.
Next you'll be telling me that Paris wasn't elected President.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
