Hackers Expose 'Critical' Wi-Fi Driver Flaw

Who knows if this is a serious flaw or not? They used a special wireless device (not the one internal to the MAC). They didn't disclose the type of device used or why then needed a special device. It also appears that they used an ad hoc connection -- something you generally shouldn't do except in special circumstances where you know the computer you are connecting to is trusted.

Did they break an encrypted network? Or did they just connect to an open device?

There may well be a m>

They also were silent in the stuff I read about whether this was an exploit as they came out of the box or if there had be changes (and if so which ones) to the system preferences. Also quiet as to whether this was an exploit in every flavor of Mac or just the MacBook (or even just the newer MacBook., what about the older MacBook Pros. Many more questions asked than answered.

On Thu, 03 Aug 2006 23:23:13 GMT, Kurt Ullman wrote in :

According to The Register :

In all cases the attack only requires that a wireless device is switched on. A user need not be connected to a wireless network for the attack to succeed because drivers are commonly configured by default to continuously seek out available wireless networks. Maynor said that acute time pressures on driver developers contributed to the underlying vulnerabilities exploited by the attack.

See also "Hijacking a Macbook in 60 Seconds or Less - Security Fix"

One of the dangers of this type of attack is that a machine running a vulnerable wireless device driver could be subverted just by being turned on. The wireless devices in most laptops -- and indeed the Macbook targeted in this example -- are by default constantly broadcasting their presence to any network within range, and most are configured to automatically connect to any available wireless network.

But according to Maynor and Ellch, this attack can be carried out whether or not a vulnerable targeted laptop connects with a local wireless network. It is, they said, enough for a vulnerable machine to have its wireless card active for such an attack to be successful. That's a trivial demand, given that most wireless devices embedded in laptops these days are switched on by default and are configured to continuously seek out available wireless networks.

Because the software that powers these wireless devices operates at such a fundamentally low level of the operating system, traditional system safeguards like firewalls and anti-virus software most likely will not stop the operating system from accepting a maliciously crafted network probe from an attacker seeking to exploit device driver-specific flaws. The result, said Maynor, is that a system using poorly designed device drivers is vulnerable to compromise just by doing what it was programmed to do.

But that explanation eclipses the larger point that Maynor and Ellch said they are trying to get across: Namely, that wireless device drivers are largely developed and written by an odd mix of hardware and software developers in an environment where time-to-market often trumps any thorough code review for potential security flaws.

Apple -- like many computer manufacturers -- outsources the development of its wireless device drivers to third parties. In Apple's case, the developer in question is Atheros, a company that devises drivers for a number of different wireless cards, each designed with drivers specific to the operating systems on which they will be used.

Maynor and Ellch also found two different device driver flaws for wireless products aimed at Windows systems. This is notable because it points out a security loophole in the way that Microsoft has traditionally processed device drivers. Any time a Windows XP user tries to install a device driver, the system checks whether that driver has been "signed" or approved by Microsoft so as not to cause system stability problems. Many third-party wireless cards designed for Windows systems are not signed by Microsoft, and the system will throw up a warning to that effect any time a user tries to install an unsigned device driver.

But according to Maynor and others, Microsoft only recently began testing whether its approved or "signed" device drivers introduced unforeseen security weaknesses into the system. Microsoft is trying to rectify that problem with Windows Vista -- the next version of its operating system by only allowing the installation of device drivers that have met the company's security testing procedures.

They did not break wireless encryption. Ellch and Maynor claim that this exploit works at the device driver level even if the target computer does not connect to a wireless network, but that was not what they demonstrated. They had an Apple MacBook, using an unnamed USB wireless adapter with an unnamed device driver, deliberately connect to an infrastructure network created by a Dell laptop. In the video, Maynor claims this was done "for the ease of this demo". The video is available at .

No information was provided about the configuration of the target machine, nor was a satisfactory explanation given for having the target machine connect to the network. Without that information, the dog and pony show of creating, opening, and deleting files on the target machine, as well as the "look no wires!" finale, are largely meaningless. Until Ellch and Maynor come across with more information, they should be regarded as the Pons and Fleischmann of wireless security.

"another computer set up as an access point"

This wasn't adhoc, their computer was advertising itself as an access point. Not unlike a wardriver honeypot.

Presumably they added a nominal WiFi card so they could prove their point. Or, maybe, it was a staged presentation altogether.

On Fri, 4 Aug 2006 00:20:49 +0000 (UTC), snipped-for-privacy@XReXXHacke.usenet.us.com wrote in :

Doubtful, given their reputations, and not terribly surprising, given Intel's recent massive security patches for Centrino, which won't get installed by many victims ... er ... users. [sigh]

The only apparent reason for using a Mac at all was that Ellch and Maynor were peeved at Apple's advertising and at Mac users' supposedly smug attitude toward security.

On Fri, 04 Aug 2006 01:03:22 GMT, snipped-for-privacy@earthlink.net (Neill Massello) wrote in :

Yep, but it seems to have backfired -- they probably should have shown a Windows exploit as well.

On Thu, 3 Aug 2006 18:14:36 -0600, snipped-for-privacy@newsguy.com (Neill Massello) wrote in :

With all due respect, they have considerably more credibility than Pons and Fleischmann, particularly given the recent massive Intel patch for Centrino. I think keeping details from the general public until vendors have a chance to respond was the responsible and reasonable thing to do.

A more significant failing is that the demonstration didn't actually demonstrate the most alarming element of this supposed exploit, namely that a wireless client can be cracked even before it joins a wireless network. This discrepancy between what was claimed could be done and what was actually demonstrated was not adequately explaned.

So you'd rather keep your head in the sand, ostrich-like, than take effective action? G'head, leave you ass in the air, exposed to being hacked, while trying to discredit the sources. Meanwhile, smarter folks will simply upgrade their firmware and reconfigure their devices to avoid the risks.

Right, and if you know the device driver is susceptible to these types of attack, AND you know the OS the computer is running then it's possible to construct a hack that'll break into it. Things like buffer overflow exploits are not trivial to create. They often require multiple steps to essentially "build" the final attack vector. Think of it as putting small pieces of the code into place, merely a few bytes at a time. Once all the bytes are in place then execute them to open the door to a wider attack, or the next stage. Like 'kill the firewall' or merely reset a login password. If something can attack from the device driver level, and get code to execute, then there's little in the OS is going to protect you.

All the more reason to NEVER use devices in their default or 'overly promiscuous' modes. While some of the 'automagic' features are incredibly convenient, they don't come without greater risks. Whether or not this hack depends on such things is an open question.

But it does indicate that rigorously tested software, even at device-driver levels, continues to be necessary. It's hard (impossible?) to make completely bulletproof software. The steps necessary to ward off such attacks are often as complicated, if not more so, than whatever the program's actual purpose might be. Doing input and buffer checks, at every level, adds to the complexity and slows the speed of the program; not to mention the money to pay the developers to do it. But unless it's taken into account at the basic level then hacks like this will continue to appear.

But hey, I'm glad they took shots at first Apple for it.

On Fri, 4 Aug 2006 10:57:04 -0400, "Bill Kearney" wrote in :

Not if you look beyond the popular operating systems. True microkernels can isolate even device drivers in their own processes (contexts) to prevent this kind of compromising (with other benefits as well, including robustness and stability). The real problem is Intel processor architecture, which has so much process (context) switching and inter-process communication overhead that popular operating systems resorted to running these functions in the kernel, thus foregoing this kind of protection (and robustness and stability). A related problem is weak memory management, including lack of Data Execution Prevention until recently. For more information on microkernels, see .

It was because Pons and Fleischmann did have some credibility as scientists that their claim got any attention. Their credibility collapsed because their claim did, not the other way around.

The details that Ellch and Maynor omitted weren't just those that would enable somebody to reproduce the exploit. They were also those that would allow some preliminary judgement about the nature and extent of the security threat. What chipset and driver did they use? We don't know. How was the target machine configured? We don't know. Why didn't they demonstrate the full extent of the exploit without first associating the target with the network? We don't know.

It isn't "responsible and reasonable" to make alarming claims, provide essentially no supporting information, and present a glib but incomplete demonstration. It's a publicity stunt. This announcement and its accompanying "demonstration" were, at the very least, premature.

"Bill Kearney" hath wroth:

If it wasn't for the sterling credentials of those presenting the wirless driver exploit, it would probably be dismissed as alarmist and possibly fabricated. Methinks Ellch and Maynor might have a slightly different agenda. Major security exploits are normally not released in the middle of security conventions unless those making the presentation are after publicity. It could easily have been released in one of the security mailing lists, where exploit details are usually not released until after those affected are informed. Some time is allowed for the manufacturers to review the problem and offer fixes. Peer review and comments in the mailing lists are also necessary to make sure there were no oversights and errors.

However, the problem is a bit different when giving a live public demonstration. The trick is to show that there is a problem, but to not leak exploit details to the hackers. Trying to do that effectively at the Black Hat convention is a guaranteed loser. Everyone present is going to want exploit details. Those with a clue are going to run home and crank out exploit scripts. Meanwhile, the manufacturers are in a state of panic, and the trade press is sure to expand this into the inevitable demise of all things wireless.

In my opinion, the only thing positive that might come out of this is the publicity received by Ellch and Maynor. Everything else is in disarray and subject to many questions. Like Fleischmann and Pons (cold fusion), they got their publicity and nothing else useful.

How? It's a driver issue. According to the story line, you don't even need to be connected to be successfully attacked. Just have the client radio enabled. I have my doubts after reading the presentations and watching the video clip. There were some things involved in the demo that were totally un-necessary. Why did they use a laptop as an access point? Why do they claim that a connection is not necessary, and then run the demonstration while connected. Etc. Methinks the smart people will not panic, just wait and see, and perhaps turn off their wireless clients or radios when not in use.

Straw man. There's a middle ground between an ostrich and Chicken Little.

And meanwhile, you should turn off the wireless cards in all your computers.

| Not if you look beyond the popular operating systems. True microkernels | can isolate even device drivers in their own processes (contexts) to | prevent this kind of compromising (with other benefits as well, | including robustness and stability). The real problem is Intel | processor architecture, which has so much process (context) switching | and inter-process communication overhead that popular operating systems | resorted to running these functions in the kernel, thus foregoing this | kind of protection (and robustness and stability). A related problem is | weak memory management, including lack of Data Execution Prevention | until recently. For more information on microkernels, see | .

Saying "The real problem" is misleading. While it is certainly real, the more correct statement is "A real problem". There are others, too, and just as real. The biggest one I'm aware of is management trying to make technical decisions beyond that scope of capability, then trying to assert the authority to do so, anyway, by claiming it to be a "business decision". Completely inappropriate time schedules are often to blame. But what often happens is scheduling the elements of the project under false ideas of how long some aspect (like writing the driver) will take. Because a lot of driver developers _can_ deliver functional code fast, managers tend to have the idea that such delivery times represent a _correct_ driver. Performance and functionality are easy to test, reliability and security under conditions not anticipated are much harder.

You can have it delivered sooner, run faster, or work correct. Pick two. Guess which two that most managers usually end up picking.

Don't misinterpret this post as saying the problems with the Intel x86 class CPUs are not relevant. But ways to work around these problems are known. They usually do take extra time, which managers don't like.

On Fri, 04 Aug 2006 01:38:39 GMT John Navas wrote: | On Thu, 3 Aug 2006 18:14:36 -0600, snipped-for-privacy@newsguy.com (Neill Massello) | wrote in : | |>No information was provided about the configuration of the target |>machine, nor was a satisfactory explanation given for having the target |>machine connect to the network. Without that information, the dog and |>pony show of creating, opening, and deleting files on the target |>machine, as well as the "look no wires!" finale, are largely |>meaningless. Until Ellch and Maynor come across with more information, |>they should be regarded as the Pons and Fleischmann of wireless |>security. | | With all due respect, they have considerably more credibility than Pons | and Fleischmann, particularly given the recent massive Intel patch for | Centrino. I think keeping details from the general public until vendors | have a chance to respond was the responsible and reasonable thing to do.

As long as "a chance" is a finite time frame that cannot be extended beyond what is "reasonable" as defined not by the vendor. But just what really is reasonable can be hard to define. Maybe the driver has to be rewritten from scratch because it had a fundamentally flawed design. That could take more time than even the original project. OTOH, the vendor should incur whatever cost that involves to get it done in the expected time frame.

On 4 Aug 2006 18:12:54 GMT, snipped-for-privacy@ipal.net wrote in :

With all due respect, such work-arounds aren't a real solution, just bandaids, since they can't provide real robustness -- only hardware checking can do that.