“You’ve probably heard of full disclosure, the security philosophy that calls for making public all details of vulnerabilities. It has been the subject of debates among researchers, vendors, and security firms. But the story that grabbed most of the headlines at the Black Hat Briefings in Las Vegas last week was based on a different type of disclosure. For lack of a better name, I’ll call it faux disclosure. Here’s why.”
Now that is a interesting story. Wouldn’t surprise me either. Maybe we should all be keepig our eye on Apple instead of always scrutinizing the evil empires actions?
Yes, this includes *nix OS that are using WiFi. It is a flaw in the implementation from my understanding, though my standard disclaimer of not being sure holds. It is not a specific card or OS, but all cards and all OS. Basically nothing new, as WiFi itself has been insecure from the beginning, even with the use of WEP and such. Does this really surprise anyone? To me it is like the person who gets a wireless keyboard, then wonders why people can watch what they type. It is not secure, or rather not unbreakable, and can be done fairly easy with the right tools.
While its true that the transmission is insecure, without knowing more about the exploit, we don’t know how to protect against it. Will a basic firewall negate the vulnerability? Or is it a bug in the networking stack that will pass all traffic through regardless. I dont use wireless when I do anything sensistive, who cares if someone watches me surf OSNEWS. But I dont want there to be a backdoor into my system because of it.
It’s my understanding the problem is not in the network stack at all, it’s related to the way the driver copies data from the hardware registers into a kernel buffer, before it reaches the network stack.
This is just one of the many reasons to despise 3rd-party proprietary drivers in kernelspace. Who is liable for this stuff? The hardware vendor will claim that the vulnerability doesn’t exist on platform X or that the problem could have been avoided if the OS vendor had done steps 1, 2, and 3. The OS vendor will claim that there’s no way that they could have found the vulnerability in the proprietary code without reverse engineering techniques.
These companies are rushing products to market with drivers that run with elevated privileges and can cause massive losses if there’s a bug–and there’s little we can do to protect ourselves. Where’s Ralph Nader when you really need him?
It is suspected that this flaw is in the atheros binary blob that all atheros drivers use.
It is suspected that this flaw is in the atheros binary blob that all atheros drivers use.
Don’t *nix, Windows and Mac use ‘radically’ different driver models? I’m not knowledgeable in that area, but I’d sooner suspect it’s a hardware flaw in a particular chipset that allows for bufferoverflows within kernelspace.
Yes, this includes *nix OS that are using WiFi. It is a flaw in the implementation from my understanding, though my standard disclaimer of not being sure holds. It is not a specific card or OS, but all cards and all OS.
No, OpenBSD has been given a clean slate for one, owing to their reverse-engineered and written-from-scratch approach. By the same reasoning I would assume that other flavors of BSD plus at least some of the native linux drivers would be ok as well.
This isn’t something to do with Apple or Microsoft or the distros, it’s to do with the drivers being pumped out of the chipset makers (as rajj pointed out above).
Of course, hard to know for sure until full details are released.
Nope, I am pretty sure OpenBSD is the only open source system not using the HAL, it’s definately the only BSD not using it.
lot of them, so………….
Don’t *nix, Windows and Mac use ‘radically’ different driver models?
Maybe, but vendors still reuse as much driver code between platforms as they can, so the bug probably lies in this common code.
Really the buck stops with the vendor of the product and/or hardware where the fault exists. If the hardware or driver is provided by vendor X, then to me it’s their responsibility to ensure their product operates properly and securely.
I really grow tired of this tollerance of computer faults. People don’t accept it from their car alarms, their home alarms, their televisions, their ovens or lawn mowers, yet for some reason people seem to tollerate it from computers.
This idea that people blame the OS vendor for their implementation of a dependency doesn’t wash with me. If you cannot make it secure in the given framework, don’t release it.
This vulnerability is one good example for open systems.
Edited 2006-08-09 02:01
“I really grow tired of this tollerance of computer faults. People don’t accept it from their car alarms, their home alarms, their televisions, their ovens or lawn mowers, yet for some reason people seem to tollerate it from computers.”
I’ve often wondered about this myself and it is rather ridiculous. With computers and hardware, it’s so common that things don’t work as advertised that it’s almost a given.
“It is a flaw in the implementation from my understanding, though my standard disclaimer of not being sure holds.”
Well, there’s no way to know. A video is not proof of anything, disclosure and proof-of-concept code is.
“Basically nothing new, as WiFi itself has been insecure from the beginning, even with the use of WEP and such”
This problem is in an entirely different problem domain and has nothing to do with WIFI per se and everything to do with drivers in general.
“It is not secure, or rather not unbreakable, and can be done fairly easy with the right tools.”
Given enough time and resources everything is breakable.
They still try the “security by obscurity” approach. By silencing the independant researchers and simultaniously NOT fixing the flaw, they put a part of the internet infrastructure at risk.
It maybe would be a good thing, if some cracker would find that exploit and launch some attacks through it. That would maybe give the researchers some arguments the next time they find such a flaw.