It must have been a dream... #
Posted Monday 10th November 2008 14:27 GMT
..for a minute then I thought I read about a security vulnerability in Linux..
Posted Monday 10th November 2008 14:27 GMT
..for a minute then I thought I read about a security vulnerability in Linux..
Posted Monday 10th November 2008 14:27 GMT
You should use native Linux drivers or tell the Hardware manufactures you won't buy from them.
Posted Monday 10th November 2008 14:29 GMT
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.
Posted Monday 10th November 2008 14:29 GMT
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?
Posted Monday 10th November 2008 14:29 GMT
Oh wait....Linux.
</smug>
Posted Monday 10th November 2008 14:29 GMT
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.
Posted Monday 10th November 2008 14:29 GMT
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.
Tony.
Posted Monday 10th November 2008 14:29 GMT
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.
Posted Monday 10th November 2008 14:29 GMT
....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.
Posted Monday 10th November 2008 14:29 GMT
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.
Posted Monday 10th November 2008 14:29 GMT
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.
Posted Monday 10th November 2008 14:40 GMT
No "Ha you see Linux has vulns as well" "No it's a windows component causing the problem!" argument yet.... Must be Monday :)
Posted Monday 10th November 2008 16:50 GMT
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.
Posted Monday 10th November 2008 18:24 GMT
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.
Posted Tuesday 11th November 2008 11:04 GMT
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.
Sign up, sign up for The Register's weekly IT security newsletter - click here