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 to …
It must have been a dream...
..for a minute then I thought I read about a security vulnerability in Linux..
This is why ...
You should use native Linux drivers or tell the Hardware manufactures you won't buy from them.
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.
Its not like the native driving I'm using at the moment is very stable, in fact I've been getting kernel panics recently and I suspect this driver (rtl8187) to be the culprit.
PS: Where's the bleeding penguin icon when you need it?
Will we have to wait for Patch Tuesday two months from now?
In each case, the SVN commits relevant to this appear to be off-by-ones (e.g. > instead of >=, "size" instead of "size+1"), although they are mixed in with fixes for other problems so perhaps I missed something.
It's amazing the difference a "+1" can make to some code.
Of course you're only vulnerable if you have NDISWrapper enabled.
This is only a problem if your wireless chipset isn't natively supported and you enable it using NDISWrapper. If, like me, you take care to buy wireless cards with native drivers, this isn't an issue.
If so, it won't affect the majority of wireless cards, which are supported natively by the kernel. NDISWrapper - as the name suggests - just allows Windows drivers to be used for unsupported cards.
In other words - storm-inna-teacup.
....coz I can't get wireless to work with my Ubuntu...or is that a security feature?
Linux? To the Gods, maybe....to mere mortals like me it's frustration.
Same old but why use NDISwrapper for Wi-Fi anyway?
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.
NDIS is a wrapper
but of course a bug is a bug, and it appears to be happening at the wrapper level.
There are not too many who use NDIS nowadays, but those who do will probably figure as a large percentage of those who don't update their distro either.
No "Ha you see Linux has vulns as well" "No it's a windows component causing the problem!" argument yet.... Must be Monday :)
Re: This is why ...
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.
Ok so I was being a tad sarcastic. And I accept that this is a bug in a Linux component.
But if you want to run Linux on your lap top/palm top get one that works or complain to the vendor trying to sell you it.
Hang on a minute
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.
- iPad is an iFAD: Now we know why Apple went running to IBM
- Updated HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
- Apple orders huge MOUNTAIN of 80 MILLION 'Air' iPhone 6s
- PROOF the Apple iPhone 6 rumor mill hype-gasm has reached its logical conclusion
- Black Hat anti-Tor talk smashed by lawyers' wrecking ball