LAS VEGAS-Wi-Fi-enabled computers are sitting ducks for code execution
attacks because of gaping flaws in wireless drivers shipped on both Mac and
Windows systems, security researchers warned at the Black Hat Briefings
security conference here.
A pair of hackers-David Maynor and Jon Ellch-demonstrated such a break-in on
an Apple MacBook laptop fitted with a wireless card that was broadcasting
its presence to another computer set up as an access point.
During the demonstration, the researchers were able to take complete control
of the MacBook via a specific vulnerability in the device driver code that
sits between the operating system and the wireless card.
Maynor and Ellch did not release details or exploit code for the flaw, which
affects a wide range of Wi-Fi card manufacturers. The researchers have
notified the affected companies and are working closely to identify the
vulnerable code.
"This is not a big problem today. But, it should be something to take
seriously now before it becomes a big, big problem a year or two from now,"
said Maynor, who works as a senior researcher at Atlanta-based SecureWorks.
"The OS vendors have been hardening the operating system a lot, so now
attackers have two choices. They can go up to the application level, or they
can go lower to the device driver level," Maynor said, warning that Wi-Fi
drivers present an easy-to-exploit target.
"You've got to keep in mind that [malicious] people with an unlimited amount
of time can spend a lot of time looking at these things," he added.
Ellch, a well-known security expert who uses the hacker moniker "Johnny
Cache," made it clear that the issue is not specific to Apple's Mac
computers. "This isn't an Apple problem or a Microsoft problem. This is
something that's problematic across the industry," he said.
However, Maynor said the MacBook was used in the demo as a retort to the
latest Apple commercials. "We don't want to bash Mac. I'm a big fan of Mac.
But those commercials are just [annoying]," he said.
Ellch, a creator of wireless hacking tools, also used the Black Hat stage to
discuss design flaws in the 802.11 link-layer wireless protocol. He
described 802.11 as an "overly complicated" protocol that has not been
implemented securely by many vendors.
He also showcased a new Wi-Fi fingerprinting technique that can be used by
attackers to spy on target systems.
The presentation comes just days after chip giant Intel released a trio of
security patches for critical vulnerabilities affecting its Centrino product
line.
Maynor said the Intel patches, which cover code execution holes in Centrino
drivers and Intel Pro/Wireless network connections, were not related to the
Black Hat speech. "It's pretty interesting, the timing of the [Intel]
patches, but it's not something that we were responsible for," he said.
Intel said in an alert that the most serious flaw in the Centrino wireless
driver line can be exploited to launch remote code execution attacks.
"[These flaws] could potentially be exploited by attackers within range of
the Wi-Fi station to execute arbitrary code on the target system with
kernel-level privileges. These flaws are due to a memory corruption while
parsing certain frames," Intel said.
The bugs could also lead to information disclosure and privilege escalation
attacks.
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 monster under the bed. The rational person lifts the
covers and looks.
riggor wrote:
> http://www.eweek.com/article2/0,1895...EMNL080306EOAD
>
> LAS VEGAS-Wi-Fi-enabled computers are sitting ducks for code execution
> attacks because of gaping flaws in wireless drivers shipped on both Mac and
> Windows systems, security researchers warned at the Black Hat Briefings
> security conference here.
>
> A pair of hackers-David Maynor and Jon Ellch-demonstrated such a break-in on
> an Apple MacBook laptop fitted with a wireless card that was broadcasting
> its presence to another computer set up as an access point.
>
> During the demonstration, the researchers were able to take complete control
> of the MacBook via a specific vulnerability in the device driver code that
> sits between the operating system and the wireless card.
>
> Maynor and Ellch did not release details or exploit code for the flaw, which
> affects a wide range of Wi-Fi card manufacturers. The researchers have
> notified the affected companies and are working closely to identify the
> vulnerable code.
>
> "This is not a big problem today. But, it should be something to take
> seriously now before it becomes a big, big problem a year or two from now,"
> said Maynor, who works as a senior researcher at Atlanta-based SecureWorks.
>
> "The OS vendors have been hardening the operating system a lot, so now
> attackers have two choices. They can go up to the application level, or they
> can go lower to the device driver level," Maynor said, warning that Wi-Fi
> drivers present an easy-to-exploit target.
>
> "You've got to keep in mind that [malicious] people with an unlimited amount
> of time can spend a lot of time looking at these things," he added.
>
> Ellch, a well-known security expert who uses the hacker moniker "Johnny
> Cache," made it clear that the issue is not specific to Apple's Mac
> computers. "This isn't an Apple problem or a Microsoft problem. This is
> something that's problematic across the industry," he said.
>
> However, Maynor said the MacBook was used in the demo as a retort to the
> latest Apple commercials. "We don't want to bash Mac. I'm a big fan of Mac.
> But those commercials are just [annoying]," he said.
>
> Ellch, a creator of wireless hacking tools, also used the Black Hat stage to
> discuss design flaws in the 802.11 link-layer wireless protocol. He
> described 802.11 as an "overly complicated" protocol that has not been
> implemented securely by many vendors.
>
> He also showcased a new Wi-Fi fingerprinting technique that can be used by
> attackers to spy on target systems.
>
> The presentation comes just days after chip giant Intel released a trio of
> security patches for critical vulnerabilities affecting its Centrino product
> line.
>
> Maynor said the Intel patches, which cover code execution holes in Centrino
> drivers and Intel Pro/Wireless network connections, were not related to the
> Black Hat speech. "It's pretty interesting, the timing of the [Intel]
> patches, but it's not something that we were responsible for," he said.
>
> Intel said in an alert that the most serious flaw in the Centrino wireless
> driver line can be exploited to launch remote code execution attacks.
> "[These flaws] could potentially be exploited by attackers within range of
> the Wi-Fi station to execute arbitrary code on the target system with
> kernel-level privileges. These flaws are due to a memory corruption while
> parsing certain frames," Intel said.
>
> The bugs could also lead to information disclosure and privilege escalation
> attacks.
>
>
>
In article <8ovAg.41749$Nt.15252@bignews8.bellsouth.net>,
Jerry Park <NoReply@No.Spam> wrote:
> 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 monster under the bed. The rational person lifts the
> covers and looks.
>
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 <kurtullman@yahoo.com>
wrote in
<kurtullman-82C157.19231203082006@customer-201-125-217-207.uninet.net.mx>:
>In article <8ovAg.41749$Nt.15252@bignews8.bellsouth.net>,
> Jerry Park <NoReply@No.Spam> wrote:
>
>> 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 monster under the bed. The rational person lifts the
>> covers and looks.
>>
> 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.
According to The Register
<http://www.theregister.com/2006/08/03/wifi_driver_hack/>:
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"
<http://blog.washingtonpost.com/securityfix/2006/08/hijacking_a_macbook_in_60_seco_1.html>
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.
[MORE]
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
Jerry Park <NoReply@no.spam> wrote:
> 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.
"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.
--
---
Clarence A Dold - Hidden Valley Lake, CA, USA GPS: 38.8,-122.5
>Jerry Park <NoReply@no.spam> wrote:
>> 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.
>
>"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.
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]
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Fri, 04 Aug 2006 01:03:22 GMT, neillmassello@earthlink.net (Neill
Massello) wrote in
<1hjic0u.12s2zgq1i2q9jqN%neillmassello@earthlink.n et>:
>Kurt Ullman <kurtullman@yahoo.com> wrote:
>
>> 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.
>
>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.
Yep, but it seems to have backfired -- they probably should have shown a
Windows exploit as well.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Thu, 3 Aug 2006 18:14:36 -0600, massello@newsguy.com (Neill Massello)
wrote in <1hji9oy.1gssc3k1xfd159N%massello@newsguy.com>:
>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.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
> Until Ellch and Maynor come across with more information,
> they should be regarded as the Pons and Fleischmann of wireless
> security.
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.
> 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.
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"
<wkearney99@hotmail.com> wrote in
<NuGdnbyyFNbc_U7ZnZ2dnUVZ_vmdnZ2d@speakeasy.net> :
>> 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.
>
>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.
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
<http://en.wikipedia.org/wiki/Microkernel>.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
>> Until Ellch and Maynor come across with more information,
>> they should be regarded as the Pons and Fleischmann of wireless
>> security.
>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.
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.
>Meanwhile, smarter folks
>will simply upgrade their firmware and reconfigure their devices to avoid
>the risks.
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.
> 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.
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.
On Fri, 04 Aug 2006 15:11:49 GMT John Navas <spamfilter0@navasgroup.com> wrote:
| 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
| <http://en.wikipedia.org/wiki/Microkernel>.
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.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-08-04-1302@ipal.net |
|------------------------------------/-------------------------------------|
On Fri, 04 Aug 2006 01:38:39 GMT John Navas <spamfilter0@navasgroup.com> wrote:
| On Thu, 3 Aug 2006 18:14:36 -0600, massello@newsguy.com (Neill Massello)
| wrote in <1hji9oy.1gssc3k1xfd159N%massello@newsguy.com>:
|
|>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.
--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-08-04-1314@ipal.net |
|------------------------------------/-------------------------------------|
>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.
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.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Fri, 04 Aug 2006 16:30:25 GMT, neillmassello@earthlink.net (Neill
Massello) wrote in <1hjjclx.cj6fuu7y8jobN%neillmassello@earthlink.net >:
>John Navas <spamfilter0@navasgroup.com> wrote:
>
>> 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.
>
>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.
That depends on whether or not more information is being provided to
affected organizations, as claimed. Thus far there hasn't been any
suggestion that it hasn't, so I think this criticism is, at the very
least. premature. ;) The recent massive Intel security patch also
lends credibility to the claims.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
>>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.
>
>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.
I suspect there's more going on here than meets the eye. A big problem
in security is getting vendors to pay proper attention. My guess is
that these guys got fed up with the lack of concern, and decided to
build a fire under them with this public presentation. If so (or
something like that), my own opinion is, "Bravo!"
I'm frankly sick and tired of vendors _knowingly_ shipping badly flawed
products. It's the major reason I largely dropped out of beta testing
-- I have a long list of _major_ bugs I found as a beta tester that were
left unfixed in released products (which I'm unable to disclose due to
NDAs).
I'd like to respond to the people who commented on yesterday's post
about the video's depiction of the use of a third-party wireless card
on the Macbook. I spent more than an hour with Dave Maynor watching
this exploit in action and peppering him with questions about it.
During the course of our interview, it came out that Apple had leaned
on Maynor and Ellch pretty hard not to make this an issue about the
Mac drivers -- mainly because Apple had not fixed the problem yet.
Maynor acknowledged that he used a third-party wireless card in the
demo so as not to draw attention to the flaw resident in Macbook
drivers. But he also admitted that the same flaws were resident in
the default Macbook wireless device drivers, and that those drivers
were identically exploitable. And that is what I reported.
I stand by my own reporting, as according to Maynor and Ellch it
remains a fact that the default Macbook drivers are indeed
exploitable.
To all of the commenters who complained about why this demo was not
shown live, I refer you back to the text of the blog post, which
pointed out the dangers inherent in showing this type of exploit live
to a room overflowing with curious hackers who would like nothing
more than to capture a copy of the exploit wirelessly and experiment
with it.
Again, the whole point of this story was not to pick on Macs, but to
point to a security issue that affects multiple operating systems and
one that is long overdue for some serious code review by the
companies that OEMs rely upon to produce this software.
As always, thanks for all the comments. Keep them coming.
-- Brian Krebs
>>Meanwhile, smarter folks
>>will simply upgrade their firmware and reconfigure their devices to avoid
>>the risks.
>
>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?
Probably because the MacBookPro has Airport functionality built into it.
>Why do they claim that a connection is
>not necessary, and then run the demonstration while connected. Etc.
I can think of a number of legitimate reasons. Why assume otherwise?
>Methinks the smart people will not panic, just wait and see, and
>perhaps turn off their wireless clients or radios when not in use.
Panic is never a good idea. Nonetheless I'm now concerned about the
Atheros wireless device in my own notebook computer, and even more for
ones I've deployed for clients and friends, since that was reportedly
the hardware used in the demo.
I've always turned off my own wireless when not needed, not only for
security, but also for power saving and less annoyance. (I like how
easy that is with a ThinkPad, one of the reasons I use and recommend
them.) However, I really can't expect all my clients and friends to do
so.
Until this is all sorted out, I've decided to:
1. Monitor updates and security for clients and friends even move
carefully than usual.
2. Use Wireless Client Bridges instead of integrated wireless adapters
as much as possible.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
John Navas <spamfilter0@navasgroup.com> hath wroth:
>I suspect there's more going on here than meets the eye. A big problem
>in security is getting vendors to pay proper attention. My guess is
>that these guys got fed up with the lack of concern, and decided to
>build a fire under them with this public presentation. If so (or
>something like that), my own opinion is, "Bravo!"
I might agree with your analysis if they had previously even hinted
that there was a problem in one of the security mailing lists. Whether
the motivation was getting the attention of the vendors or simple
publicity, they are certainly guilty of grandstanding.
>I'm frankly sick and tired of vendors _knowingly_ shipping badly flawed
>products.
Good idea. Let's attach a government mandated warning label to
wireless routers.
DEPT of HOME SECURITY WARNING
This device contains firmware known to the government as
being potentially hazardous to your data security. The
manufacturer does not warrant against contageous infections
unless a concienciously applied program of updates and fixes
are applied for the duration of the product lifetime.
>It's the major reason I largely dropped out of beta testing
>-- I have a long list of _major_ bugs I found as a beta tester that were
>left unfixed in released products (which I'm unable to disclose due to
>NDAs).
Ditto. I busted my ass playing beta tester for various products,
where the vendor largely ignored my findings.
Liebermann's Axiom: Features and functions get added faster than bugs
get fixed eventually resulting in a bloated buggy mess.
> During the course of our interview, it came out that Apple had leaned
> on Maynor and Ellch pretty hard not to make this an issue about the
> Mac drivers -- mainly because Apple had not fixed the problem yet.
How could Apple lean on them unless Apple was considering hiring them
to get involved in repairing their security problem (or image)?
> To all of the commenters who complained about why this demo was not
> shown live, I refer you back to the text of the blog post, which
> pointed out the dangers inherent in showing this type of exploit live
> to a room overflowing with curious hackers who would like nothing
> more than to capture a copy of the exploit wirelessly and experiment
> with it.
Naw. Stealing the disks and cdroms is easier.
>Probably because the MacBookPro has Airport functionality built into it.
They could have just as easily used an Airport or Airport Express.
>>Why do they claim that a connection is
>>not necessary, and then run the demonstration while connected. Etc.
>
>I can think of a number of legitimate reasons. Why assume otherwise?
I can't think of any reason that a client driver exploit would require
an active connection to function. Perhaps I'm missing something here.
However, since the actual details of the exploit have not been
released, I'll leave this point to conjecture.
On Sat, 05 Aug 2006 10:52:56 -0700, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote in
<uql9d21celm279qmmin5op36s5mul4933p@4ax.com>:
>John Navas <spamfilter0@navasgroup.com> hath wroth:
>
>>I suspect there's more going on here than meets the eye. A big problem
>>in security is getting vendors to pay proper attention. My guess is
>>that these guys got fed up with the lack of concern, and decided to
>>build a fire under them with this public presentation. If so (or
>>something like that), my own opinion is, "Bravo!"
>
>I might agree with your analysis if they had previously even hinted
>that there was a problem in one of the security mailing lists.
There's nothing sacred about security mailing lists, which are actually
controversial. I personally think it's sufficient and reasonable to
contact companies directly, as they apparently did.
>Whether
>the motivation was getting the attention of the vendors or simple
>publicity, they are certainly guilty of grandstanding.
I personally think the public is at least as well-served by the
publicity.
>> During the course of our interview, it came out that Apple had leaned
>> on Maynor and Ellch pretty hard not to make this an issue about the
>> Mac drivers -- mainly because Apple had not fixed the problem yet.
>
>How could Apple lean on them unless Apple was considering hiring them
>to get involved in repairing their security problem (or image)?
Pressure can of course be applied in other ways. Apple is known to be
quite litigious, for example.
>> To all of the commenters who complained about why this demo was not
>> shown live, I refer you back to the text of the blog post, which
>> pointed out the dangers inherent in showing this type of exploit live
>> to a room overflowing with curious hackers who would like nothing
>> more than to capture a copy of the exploit wirelessly and experiment
>> with it.
>
>Naw. Stealing the disks and cdroms is easier.
But not as much fun.
>>Probably because the MacBookPro has Airport functionality built into it.
>
>They could have just as easily used an Airport or Airport Express.
Not necessarily. The MacBook is much easier to program.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
In article <eei9d2hd8feq2vfag2cjrjltvjiq9ccfje@4ax.com>,
John Navas <spamfilter0@navasgroup.com> wrote:
> On Fri, 04 Aug 2006 09:46:34 -0700, Jeff Liebermann
> <jeffl@comix.santa-cruz.ca.us> wrote in
> <u7t6d2la1h2b6rju4ho1soh0laiatl0m08@4ax.com>:
>
> I stand by my own reporting, as according to Maynor and Ellch it
> remains a fact that the default Macbook drivers are indeed
> exploitable.
Dan Rather stood by his whilst being shown the door because it had be
discredited. NBC stood by the exploding gas tanks in the trucks report
whilst it was being shown they (sorta like in this case) were using a
non-Ford part.. AKA model rocket engines.. to make their point. It
remains not a fact because as he mentioned:
> But he also admitted that the same flaws were resident in
> the default Macbook wireless device drivers, and that those drivers
> were identically exploitable. And that is what I reported.
I also thought that "admitted" was a rather interesting choice of
words in this case. Sounds like M&E said it was their fault. M&E may
have said or suggested, but hardly admitted.
In article <i3o9d2ljmrrtphb7uqge59oqcima37ntoh@4ax.com>,
John Navas <spamfilter0@navasgroup.com> wrote:
> >How could Apple lean on them unless Apple was considering hiring them
> >to get involved in repairing their security problem (or image)?
>
> Pressure can of course be applied in other ways. Apple is known to be
> quite litigious, for example.
Yeah but why just lean on them about Airport and let them use a
MacBook unimpeded. If I was Apple, I would "defend" both vigorously or
if threatening legal action on only one, it makes no sense to threaten
about Airport and let them beat up on MB.
On Sat, 05 Aug 2006 18:49:55 GMT, Kurt Ullman <kurtullman@yahoo.com>
wrote in
<kurtullman-F7090A.14495305082006@customer-201-125-217-207.uninet.net.mx>:
>In article <i3o9d2ljmrrtphb7uqge59oqcima37ntoh@4ax.com>,
> John Navas <spamfilter0@navasgroup.com> wrote:
>
>> >How could Apple lean on them unless Apple was considering hiring them
>> >to get involved in repairing their security problem (or image)?
>>
>> Pressure can of course be applied in other ways. Apple is known to be
>> quite litigious, for example.
> Yeah but why just lean on them about Airport and let them use a
>MacBook unimpeded. If I was Apple, I would "defend" both vigorously or
>if threatening legal action on only one, it makes no sense to threaten
>about Airport and let them beat up on MB.
Presumably because Apple couldn't have much to say when the exploit is
demonstrated against a non-Apple product, even when an Apple computer is
used in the demonstration. I think that was a cool way to make the
point with relative safety.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
> That depends on whether or not more information is being provided to
> affected organizations, as claimed. Thus far there hasn't been any
> suggestion that it hasn't, so I think this criticism is, at the very
> least. premature. ;) The recent massive Intel security patch also
> lends credibility to the claims.
Security researchers routinely inform "affected organizations" well in
advance and delay the splashy public presentations until there's
something available in the way of a fix. Going public before that
usually only occurs after the exploit has already appeared in the wild
or after vendors have been dragging their feet on the problem for a long
time.
No informed person is denying that there could be serious security holes
in wireless device drivers. The validity of this particular claim will
be sorted out in time. It's not so much the content of the announcement
as its timing, that bizarre demonstration, and Ellch's and Maynor's
extracurricular statements that have raised questions about their
motives and credibility.
On Sat, 05 Aug 2006 20:16:39 GMT, neillmassello@earthlink.net (Neill
Massello) wrote in <1hjllxp.18kn8wy4t5nxsN%neillmassello@earthlink.ne t>:
>John Navas <spamfilter0@navasgroup.com> wrote:
>
>> That depends on whether or not more information is being provided to
>> affected organizations, as claimed. Thus far there hasn't been any
>> suggestion that it hasn't, so I think this criticism is, at the very
>> least. premature. ;) The recent massive Intel security patch also
>> lends credibility to the claims.
>
>Security researchers routinely inform "affected organizations" well in
>advance and delay the splashy public presentations until there's
>something available in the way of a fix. Going public before that
>usually only occurs after the exploit has already appeared in the wild
>or after vendors have been dragging their feet on the problem for a long
>time.
The latter may well have been the case here, but it's actually standard
practice to disclose the existence of a security flaw and just withhold
the details until enough time has passed for a fix (which might also
have been the case here), particularly when there are ways to minimize
or avoid the risk.
>No informed person is denying that there could be serious security holes
>in wireless device drivers. The validity of this particular claim will
>be sorted out in time. It's not so much the content of the announcement
>as its timing, that bizarre demonstration, and Ellch's and Maynor's
>extracurricular statements that have raised questions about their
>motives and credibility.
I respectfully disagree.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
On Sat, 05 Aug 2006 20:16:40 GMT, neillmassello@earthlink.net (Neill
Massello) wrote in <1hjloeo.m3aclzyfd6ixN%neillmassello@earthlink.net >:
>John Navas <spamfilter0@navasgroup.com> wrote:
>
>> My guess is
>> that these guys got fed up with the lack of concern, and decided to
>> build a fire under them with this public presentation.
>
>Then they should have used better fuel: name some names and don't do any
>hand-waving during the demo.
I think they did just fine.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
In article <i0u9d2547tj9gjcsqsohmhsmvtee58l0c1@4ax.com>,
John Navas <spamfilter0@navasgroup.com> wrote:
> On Sat, 05 Aug 2006 18:49:55 GMT, Kurt Ullman <kurtullman@yahoo.com>
> wrote in
> <kurtullman-F7090A.14495305082006@customer-201-125-217-207.uninet.net.mx>:
>
> >In article <i3o9d2ljmrrtphb7uqge59oqcima37ntoh@4ax.com>,
> > John Navas <spamfilter0@navasgroup.com> wrote:
> >
> >> >How could Apple lean on them unless Apple was considering hiring them
> >> >to get involved in repairing their security problem (or image)?
> >>
> >> Pressure can of course be applied in other ways. Apple is known to be
> >> quite litigious, for example.
>
> > Yeah but why just lean on them about Airport and let them use a
> >MacBook unimpeded. If I was Apple, I would "defend" both vigorously or
> >if threatening legal action on only one, it makes no sense to threaten
> >about Airport and let them beat up on MB.
>
> Presumably because Apple couldn't have much to say when the exploit is
> demonstrated against a non-Apple product, even when an Apple computer is
> used in the demonstration. I think that was a cool way to make the
> point with relative safety.
We'll have to agree to disagree on this one. I see no advantage to
this. Especially when this opens up the possibility (that came about)
that the Dynamic Duo would start carping about how nasty Apple was to
them.
> Probably because the MacBookPro has Airport functionality built into it.
So does the MacBook, which was used as the target of the attack, not as
the attacker or access point. But Maynor didn't use the MacBook's
built-in AirPort hardware. Instead, he used a USB wireless adapter
plugged in to the side of the MacBook, something that few (if any)
MacBook owners would do.
So why use a MacBook at all? Because Ellch and Maynor don't like Apple's
advertisements and think that Mac users are smug about security.
On Sat, 05 Aug 2006 21:07:28 GMT, neillmassello@earthlink.net (Neill
Massello) wrote in <1hjlq30.a8zpqz1nryvysN%neillmassello@earthlink.ne t>:
>John Navas <spamfilter0@navasgroup.com> wrote:
>
>> Probably because the MacBookPro has Airport functionality built into it.
>
>So does the MacBook, which was used as the target of the attack, not as
>the attacker or access point. But Maynor didn't use the MacBook's
>built-in AirPort hardware. Instead, he used a USB wireless adapter
>plugged in to the side of the MacBook, something that few (if any)
>MacBook owners would do.
>
>So why use a MacBook at all? Because Ellch and Maynor don't like Apple's
>advertisements and think that Mac users are smug about security.
And because the native adapter is equally vulnerable.
--
Best regards, FAQ for Wireless Internet: <http://Wireless.wikia.com>
John Navas FAQ for Wi-Fi: <http://wireless.wikia.com/wiki/Wi-Fi>
Wi-Fi How To: <http://wireless.wikia.com/wiki/Wi-Fi_HowTo>
Fixes to Wi-Fi Problems: <http://wireless.wikia.com/wiki/Wi-Fi_Fixes>
Hackers Expose 'Critical' Wi-Fi Driver Flaw 
Linear Mode
