I took another look at the link to the paper provided in cid #13 (thanks!) and here are some observations.
The first attack follows directly from the above observation. A passive eavesdropper can intercept all wireless traffic, until an IV collision occurs.
"IV" is "initialization vector" and is the same as what is elsewhere called a "salt". The IV is 24 bits; in a previous paragraph the authors had calculated that for a access point an IV is likely to get reused after about five hours. From this we're apparently supposed to conclude that it's a trivial matter to store every packet until an IV collision occurs, and then use the contents of both packets to recover plaintext. They even seem to be aware that two packets often won't be enough, but fail to mention that you need to save and search another five hours' worth of peak-bandwidth traffic to get anywhere in that case.
To be fair, they do point out a pretty serious flaw in a particular implementation of 802.11b, specifically Lucent's, which sets the IV to zero when the card is initialized and merely increments it for each packet. That does indeed make life way too easy for crackers.
we have been able to successfully intercept WEP-encrypted transmissions by changing the configuration of the drivers. We were able to confuse the firmware enough that the ciphertext (encrypted form) of unrecognized packets was returned to us
I would say that this is likely to be well beyond the capabilities of most script kiddies, and is probably pretty easy for 802.11b equipment vendors to address.
Many 802.11 products come with programmable firmware, which can be reverse-engineered and modified to provide the ability to inject traffic to attackers. Granted, such reverse-engineering is a significant time investment (we have not done this ourselves)
Damn right they haven't. Writing drivers is enough of a pain when the hardware engineer is sitting right next to you. It's harder when you have no access to hardware docs, and harder still when the hardware vendor might actively be attempting to thwart your efforts.
The real problem is not in the paper itself, though, but in the way it was reported. Consider this conclusion, from the paper:
The protocol's problems is a result of misunderstanding of some cryptographic primitives and therefore combining them in insecure ways. These attacks point to the improtance of inviting public review from people with expertise in cryptographic protocol design; had this been done, the problems stated here would have surely been avoided.
Yeah, like there have never been any problems discovered in crypto products from the self-appointed experts. Uh huh. But I'll let that slide. Now, for contrast, here's an excerpt from the ZDnet article:
"During the design process, the crypto community wasn't invited to participate," says Goldberg, now chief scientist at Zero Knowledge Systems Inc., a privacy-software firm in Montreal.
That's a pretty inflammatory statement, and apparently not far from being an outright lie. It was irresponsible (or possibly venal) of Ian Goldberg to make such a statement, and doubly so for WSJ's Jared Sandberg. As I said before, there is a matter for serious concern here, but the scaremongering from these people is not helping. The right thing to do would have been to alert the equipment manufacturers, discreetly, and let them decide how they want to alert their customers.