Researchers Hack Wi-Fi driver to Breach Laptop

InfoWorldMike writes "Security researchers have found a way to seize control of a laptop computer by manipulating buggy code in the system's wireless device driver, reports Robert McMillan. The hack will be demonstrated at the upcoming Black Hat USA 2006 conference during a presentation by David Maynor, a research engineer with Internet Security Systems and Jon Ellch, a student at the U.S. Naval postgraduate school in Monterey, California. They used an open-source 802.11 hacking tool called LORCON (Lots of Radion Connectivity) to throw an extremely large number of wireless packets at different wireless cards and see if they fail. They declined to disclose the specific details of their attack before the August 2 presentation, but said it was potentially a huge hole because exploiters could simply sit in a public space and wait for the right type of machine to come into range to attack. "This would be the digital equivalent of a drive-by shooting," said Maynor. The victim would not even need to connect to a network for the attack to work, he said."

Comments

Disclosure?

[MostAwesomeDude]

I wonder why they haven't disclosed the details. Hopefully they contacted the card manufacturer in order to get a new driver prepared for the masses before they uncover the full exploit at the conference.

Greater problem

[Casandro]

The problem is greater than that. It's probably not a single instance of wireless drivers that has such a bug, but in fact an extremely widespread problem.

I am slowly convinced, that any larger piece of C(++)-Code which handles strings, has in fact at least one Buffer overflow.

So, what will happen. The card-manufacturer might fix the bug, nobody updates, and 20 new bugs in other drivers are found, perhaps 10 of them beeing the same bug.

What's really nice about it is that Intel recently claimed, that something like this was not probable.

So, what's the solution?

1. Educate your programmers about the programmers about the language they are using. Most people who write in C(++) don't know anything about how the language works. A C(++) Programmer without firm knownledge of assember on that plattform should never be allowed to write production-grade C(++)-Code.

2. If you cannot educate your programmers, switch your language. There are plenty of Alternatives avaliable. I mean people switched to Java for no appearent reasons. If you switch to, for example, Scheme you will get a clean object oriented language without any large speed penality.

3. Build compatible devices. Make one standard like the old soundblaster one, or the AC97 so all WLAN-cards of a certain class are buildt equal. Then you could even build WLAN functionality into the BIOS. The code would only have to be written once and therefore would be less buggy.

Re:Greater problem

[Casandro]

There are lots of device drivers in other languages.

Just think of the many DOS 3D-graphics libraries written in Pascal. Those directly accessed your hardware.

Or think of (real) Macintoshes (not those Intel thingies). Their whole firmware is written in Forth. In fact all firmware device drivers of Macs and IBM P-Series as well as Sun computers are written in Forth, it's the "Open Firmware" standard.
In fact, the first Forth system was a computer designed to controll a telescope. The Forth programm directly accessed the hardware, probably via an internal layer of sub-routines.

Then of course, if you have watched TV during the 80s you have probably seen 3D graphics going through a system entirely written in LISP, the LISP-machine.

So, why does nobody use any other language than C for that?
Well first of all, Unix was written in C. In fact it was even the reason why C was invented, to have a platform-independant "assembler" with some very limited high-level functionality.
The same language was also chosen for Windows, as well as Linux.
Now the point is, if you write a device driver for those modern OSes, you will find template programms or tutorials you just fill in your code. Those templates typically are in the language of the OS, which is now typically C.
The problem goes even further. I have seen university students studying informatics, and they don't even know a single language outside the Algol block. (=C, Pascal, C++, Java, VB...) They don't even know Forth or Lisp, let along Prolog. Some of those people have never considered looking out of their boxes into what's beyond Algol.

I'm not saying C is bad per se. What I am saying is that C may be mathematically universal, you can do everything with it in theory, but for any given slightly more complex task it's just not suitable.
If you are not convinced, write a little "derivation"-Programm in C where I can enter something like x^2 and out comes 2*x. Then look into the book "Programming in Prolog" and look at the examples, you will find one the deriving programm there has just a few lines. Maze-solving programms consist of about a handfull of lines plus a pine for every connections.
Now look at C. C seems to be so broken, that not even the compilation process itself is written in C. Look at makefiles. That's a non-algol language only designed to compile C Programms. Isn't that sick?

C is good for number-crunching, but definitely not for anything touching strings.

Re:Greater problem

[modeless]

Educating all the bad programmers in the world has always been a stupid idea. It's like saying we should stop spammers by teaching people not to click on their links, or eliminate viruses by teaching people not to open suspicious attachments, or bring about world peace by all holding hands and singing "Kumbaya". It might help just a little, but it won't solve the problem. It didn't before, it isn't now, and if you can't see the future trend, you must have some sort of learning disability.

At some point, when an entire population of users spends years using a tool wrong, you have to stop blaming the users and start fixing the tools.

Even Greater Problem

[cloricus]

No one will update. And I'm serious; no one .

I've been working with end users enough at uni and work to realise the most even the slightly geeky user will only ever upgrade their graphics card on their laptop when they are forced too.

This will be a huge problem no matter how you look at it full stop.

While on one hand I can't wait to get my hands on the sploit I'm just thinking how painful this will be unless Windows (and this is the only OS I'm worried about as most Linux and Mac users will get a new driver in their regular updates if they are effected) works out some way to force an update for all wireless drivers out there.

Re:Even Greater Problem

[jawtheshark]

even the slightly geeky user will only ever upgrade their graphics card on their laptop when they are forced too.

I know we are talking about exploits here and exploits should be fixed. I disagree, however, that you should upgrade your drivers continuously *without a good reason*.

First it requires you to keep track about all driver releases of your system (if you're a network admin, it might even be many more configurations) Upgrading some point releases will probably not do much.

Second is stability: if your system is stable with your current drivers and performs well, why would you upgrade? Upgrading drivers always jeopardizes your system. Windows might not like the driver or the combination of drivers you need. That's a good reason to standarize the drivers you put on your machines.

Third, you need to realise that a "driver update" might not even concern your hardware device. Many drivers these days are unified. Is a point-release going to affect you at all. For example, if you have an older GeForce MX2, will the latest NVidia driver include *any* changes for you? I doubt it. It might even introduce new bugs because said driver has been optimized for a newer card and breaks compatibility with your older card. The last argument of course, brings us back to point two.

Fourth: many third party drivers are bad as hell and the standard Windows drivers do a good enough job. For many devices, there is no need at all to install drivers in the first place. Do you really install the Logitec drivers for your standard 3-button/scrollwheel mouse? I most certainly do not.

Essentially, it all boils down to: if it ain't broke, don't fix it.

Is this supposed to be sarcastic?

[Steeltoe]

Clearly the solution for stopping people finding security holes is to make distributing open source hacking tools illegal. Isn't this already covered by the DMCA or do we need a new law?

When open source hacking tools are made criminal, only criminals have access to security.

I thought the purpose was to find security holes and close them?

I can only hope this is supposed to be sarcastic, but it was modded +4 interesting. With no tags or marks, over the medium it's impossible to tell.

Once again....

[Corbets]

Security is an intuitive thing. I'm not saying this could be avoided, but you can bet that I've always turned off my wireless card when I'm not using it. I never heard of anyone doing this before, but I've always figured it was possible.

Unfortunately, any bit of code that runs on your computer is a potential vulnerability. The best possible solution is to minimize what's running, and update quickly if possible... but even that isn't necessarily protection. I seriously believe that the bad guys will always be one step ahead. Makes my career in security a bitch, but at least guarantees a paycheck. ;-)

ugh. Head in Sand Defense.

[twitter]

Clearly the solution for stopping people finding security holes is to make distributing open source hacking tools illegal.

That's a bad joke, please? Bad because people might get ideas. Makers of crappy devices will soon say much the same. It makes me ill.

The real solution, of course, is to avoid crappy closed source drivers. Efforts such as ndis wrapper, while a nice, bring closed source fragility to free software. Free drivers, when broken will be fixed. Good luck getting a fix for that ancient POS you bought at the CompUSA taken care of.

Sticking your head in the sand won't fix your closed source driver. Free tools will help find the problem. Not having the tool won't make the problem disappear and the kinds of people who would bother with a "drive by" will keep doing it despite any silly laws.

Save battery = save DoS

[xav_jones]

"The victim would not even need to connect to a network for the attack to work", he said.

Presumably you must still have WiFi turned on though. To save battery life, mine is usually off unless I'm connected.

Turn it off!

[soundscape]

A perfect example of why you should ALWAYS disable your WiFi adapter when you aren't using it.

Re:OpenBSD

[SargeantLobes]

Helps explain OpenBSD's stance on not having blobs, they'd have been able to audit the driver code, and fix it quicker to boot.

My thoughts exactly. Even if this exploit creeped in to the drivers, it'll be fixed byt tomorrow (or as soon as the ppl explain how the exploit works). Others will be waiting for weeks for a binary release from wifi vendors. And the vendors'll keep quiet about it, because they don't want to lose face.

People call Theo de Raadt a hardass for his stance on blobs. Torvalds calls him "difficult", but in the end he's right.

An OS that wants to be secure can't include code or grant rights to code, of whcih it doesn't know the source. How can you call something secure, if you've got a large piece of code with lots of rights and you don't know what the hell it does?

Forth and open firmware.

[bgalehouse]

The reason that forth is such a great choice for firmware and embedded systems is twofold. First of all, it is fairly fast. There can be a lot of indirection, but it is localized to a small amount of memmory.

Second of all, and very importantly, you can fit an entire forth development environment into a few k. Might need 5-10 on these new fangled 32 bit machines. That is the whole thing, no separate compiler, runtime libraries, nothing like that. So, in the time it takes to study the gcc source enough to start porting it to a new architecture, you can write a complete forth interpreter in assembly, burn it to an eprom, and start talking to your new architecture over a serial line.

And as you might expect, much like C, the bare metal is open to you. ! and @ are the commands to store and fetch variables. But they don't just work for variables, they work for any address you want to pass them.

OpenBSD's removal of vendors' binary drivers...

[QuietLagoon]

... is starting to look a lot better every day.