Slashdot Log In
Apple Patches Wireless Drivers
Posted by
CowboyNeal
on Thu Sep 21, 2006 08:27 PM
from the back-on-track dept.
from the back-on-track dept.
Frank writes "Apple quietly released a pair of patches today to its wireless drivers. The patches (one for PowerPC, one for Intel) address distinct buffer overflow vulnerabilities found during an internal audit in response to the claim that fuzzing the drivers resulted in an exploitable failure."
Related Stories
[+]
IT: Less Than a Minute to Hijack a MacBook's Wireless 390 comments
Kadin2048 writes "As reported by Ars Technica and the Washington Post, two hackers have found an exploitable vulnerability in the wireless drivers used by Apple's MacBook. Machines are vulnerable if they have wireless enabled and are set to connect to any available wireless network, fairly close to their default state, and the exploit allows an attacker to gain "total access" -— apparently a remote root. Although the demo, performed via video at the BlackHat conference, takes aim at what one of the hackers calls the "Mac userbase aura of smugness on security," Windows users shouldn't get too smug themselves: according to the Post article, "the two have found at least two similar flaws in device drivers for wireless cards either designed for or embedded in machines running the Windows OS." Ultimately, it may be the attacks against embedded devices which are the most threatening, since those devices are the hardest to upgrade. Currently there have not been any reports of this vulnerability 'in the wild.'" According to this story at ITwire.com, they were able to exploit Linux and Windows machines, too. (Thanks to Josh Fink.)
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Details (Score:5, Informative)
"Quietly" (Score:5, Insightful)
It's in Security Update where every other update goes, and a spokesperson even talked with MacWorld about it. What's quiet about the release?
Parent
Re:"Quietly" (Score:5, Funny)
Parent
Re:"Quietly" (Score:5, Funny)
Parent
Re:"Quietly" (Score:5, Funny)
"Arr, matey -- it's International Dress Like a Pirate Day, too, dincha know?"
Parent
erhm (Score:5, Funny)
What, you expect them to loudly release a pair of patches? "Hey, everybody, our products have a flaw which allows them to be wirelessly rooted in under a minute! Better apply this patch!!!1!!one!"
Somehow I don't think that would go over too well on Wall Street.
Re:erhm (Score:5, Insightful)
Parent
There's no flaw, but heres a patch anyway (Score:3, Insightful)
Sounds like Politics (Score:3, Insightful)
I wonder if Steve is planning on running
Re: (Score:3, Funny)
Re:There's no flaw, but heres a patch anyway (Score:5, Informative)
The problem is now days everyone considers a crasher to be a security exploit, even if it can't be used to run any code.
But none of these are what the SecureWorks guys "reportedly" found. Either way, they definitely and without a doubt lied on that video. The device they attached was not a wireless device seen by the system at all. The SecureWorks guys never even stated anything, other than the community didn't have the mental capacity to understand what the exploit was.
They also said they would not release details until Apple fixed it. So I assume they'll now put up or shut up. It really all looks like a publicity stunt to sell their upcoming book [amazon.com].
Parent
Re:There's no flaw, but heres a patch anyway (Score:5, Informative)
From the security release:
CVE-ID: CVE-2006-3507
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.7, Mac OS X Server v10.4.7
Impact: Attackers on the wireless network may cause arbitrary code execution
Description: Two separate stack buffer overflows exist in the AirPort wireless driver's handling of malformed frames. An attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into a wireless network. When the AirPort is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers equipped with wireless. Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected. There is no known exploit for this issue. This update addresses the issues by performing additional validation of wireless frames.
Parent
Re:There's no flaw, but heres a patch anyway (Score:5, Informative)
But, as you quote:
IOW, this is evidently not the same vulnerability claimed by SecureWorks.
Stumulated by the brouhaha, Apple have performed a code audit. (I'd suspect they did a remarkably thorough code audit too :) They have found some problems with the PPC drivers, and they have released a patch for them. They don't appear to have found any issues with the Intel code though.
Parent
Re: (Score:2, Informative)
Very true. I wonder why they didn't catch the code said to be responsible for Johnny Cache's exploit. Maybe that's because it's Atheros' driver co
Re:There's no flaw, but heres a patch anyway (Score:5, Informative)
It sure looks like it affects Intel-based Apple laptops to me. I don't buy the spin - I think it's quite likely the SecureWorks guys are right...and if they're wrong, well then these computers are just more secure. That sounds like a /really bad thing/ to me.
Parent
Re:There's no flaw, but heres a patch anyway (Score:5, Interesting)
You highlighted the wrong part. Let me fix that for you:
Impact: Attackers on the wireless network may cause arbitrary code execution Description: Two separate stack buffer overflows exist in the AirPort wireless driver's handling of malformed frames. An attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into a wireless network. When the AirPort is on, this could lead to arbitrary code execution with system privileges. This issue affects Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers equipped with wireless. Intel-based Mac mini, MacBook, and MacBook Pro computers are not affected. There is no known exploit for this issue. This update addresses the issues by performing additional validation of wireless frames.
The same "no know exploit for this issue" line is on the other two CVEs. So, Apple is saying the the claim made by the SecureWorks guys to Krebs ("the same exploit works on the internal Airport card") is a BIG FAT LIE: they did not have an exploit or if they did, they lied when they said they had shared the details with Apple.
Parent
Re:There's no flaw, but heres a patch anyway (Score:5, Informative)
This is like most "exploits." You find a crash situation, it's some overflow of somekind, you wouldn't seg fault other wise. Everyone freaks out, it might be possible to run arbitrary code, it might not be. OpenSSL had a fairly famous one about 3 years ago, the ASN.1 decoder had a crash when you put corrupt certificates in to it, at best it was a type of DoS situation and to this day nobody has ever run arbitrary code with it.
This secureworks thing is the very worst kind of "security" out there. Thing is, just about all code of a certain size has flaws. This includes drivers. Potentially, a defect in a driver is really bad, it's trusted code that executes usually in ring-1 or ring-0. These most likely won't be the last security fixes Apple puts in to their wireless drivers, it's enough code and big enough that there will be more bugs that are found.
Now I've written more and a couple wireless drivers myself and I happen to know that there is next to no way that the secureworks "exploit" works like they claim. I'd be a lot more willing to believe it if they explained that it was a microcode flaw they found or if the device was already associated with something. Some chips, like the Atheros, have a firmware that pretty much does everything and you write not a lot more than an ethernet driver on top of it and you can have wireless, you do another layer of stuff to control some of the tweakables (channel, b or g, etc.. but those are fairly static values you poke in to registers) their firmware will do WPA, WEP, all that crap. So their microcode engine isn't your normal microprocessor, crafting code for it, enough code to associate or send arbitrary packets is an impressive task. It's also rtos based, with no memory allocation, static buffers, and while it's possible that there are some overflows, I think it's pretty unlikely. It seems very believable that you could jam crappy frames in and cause it to hang or drop them in some way but overflow with enough code space to arbitrarily establish a connection to a remote machine? It's also a long way off from the OS. Crafting some frames that cause the OS to start doing that is almost more impressive, I think it's a lower hanging fruit in many ways but you have to trick the whole stack, there are checks along the way, does the OS think it's a raw socket? That never got constructed? It can't be going through the IP stack, data will get dropped at numerous places, not the least of which would be routing. If they crashed the microcode, color me stupid, but I don't see how that get's you to a userspace process or even close to it. There are a lot of things they could reveal about it if they have a real exploit that wouldn't completely reveal the hardware in question. But let's look at that too, how many 3rd party wireless parts are their for MacOSX? 2 or 3?
Parent
Apple can stop them? Huh? (Score:2)
David
Re: (Score:2, Informative)
Apple is still adamant that SecureWorks didn't find any flaws.
Re:There's no flaw, but heres a patch anyway (Score:5, Informative)
I believe just about everyone is adamant that SecureWorks didn't find any flaws.
Since their initial statement which was launched on digg with a title that read something similar to: "Own a macbook in under 60 seconds". They have claimed the following:
- Fault works on macbooks and most other wireless hardware, platform independent.
- Apple had muscled them into not demonstrating it on apple hardware, instead 3rd party hardware.
- They had informed Apple and other companies of the fault, gave the required details and instructions.
- Will demonstrate the flaw on video as to protect the packets from being sniffed.
Now since the demonstration of the video the following has come out of the woodwork
- These updates do not patch intel based macs such as the macbook.. nor do they patch anything described by SecureWorks
- Apple had never spoken with SecureWorks or it's employees about the "flaws" before the blackhat conference.
- SecureWorks have not informed Apple or any other company of the flaws or gave required details to reproduce them.
- The demonstration on video has been dubious and clearly shows 3rd party hardware being used, with there being no proof that this is a wireless flaw or just a hoax.
- SecureWorks has gone mostly silent on the issue, and have changed their story several times, they have never released details to validate -any- of their claims.
The whole thing has been a terrible farse with the perpetrators reeling into hiding after realising that this is something which the public would want proven and not just take their word for it.
No one expects any platform to be 100% secure, but when you find a fault, particularly one as interesting as a remote wireless hack, you will instantly have a huge audience wanting it proven and demonstrated, they deserve being outcast like they have. Their methods are being publicy dealt with in the same way that a disgraced scientist would be.
Parent
Re: (Score:3, Informative)
Re:There's no flaw, but heres a patch anyway (Score:4, Insightful)
I'm with John Gruber of Daring Fireball on this: my money is on Apple telling the truth. The risks of them getting spanked should it be a lie are too high, and the number of times security companies pull stunts to drum up business doesn't look good for SecureWorks.
Parent
Re: (Score:2)
Re: (Score:2, Insightful)
Because Linux' security-fixes (about weekly since the flawed AOL-desktop-OS 2.6.* kernel-series) are always loudly announced, right?
Fucking hipocrisy.
Re:Why not... (Score:4, Insightful)
Welcome to Slashdot.
Parent
Re:Why not... (Score:5, Funny)
Cause I've been fucking Hypocrisy for years now.
Just thought they might be related.
Cause of the names you know.
Parent
Additional background info (Score:4, Informative)
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Maynor and Cache said that similar flaws existed on many platforms. They said that Intel's drivers had the flaw, and that it was funny that Intel had released a new driver version a week before Black Hat. They also said that the flaw was exploitable on the MacBook using the third-party device and drivers. And they also said that the flaw was exploitable on the Airport with Apple's own drivers.
Now I don't know who to believe in this--both parties have a stak
This does NOT make the SecureWorks story true! (Score:5, Informative)
From http://www.macworld.com/news/2006/09/21/wireless/
Apple on Thursday released a Security and AirPort update for Mac OS X that fixes vulnerabilities found in the company's wireless drivers. Apple said the issues found were the result of an internal audit of the software drivers and that no known exploits exist for the issues addressed in this update.
...
Apple has maintained that SecureWorks has provided no proof that Mac drivers are vulnerable in any way.
"They did not supply us with any information to allow us to identify a specific problem, so we initiated an internal audit," Apple spokesman, Anuj Nayar, told Macworld. "Today's update preemptively strengthens our drivers against potential vulnerabilities, and while it addresses issues found internally by Apple, we are open to hearing from security researchers on how to improve security on the Mac."
Re:This does NOT make the SecureWorks story true! (Score:5, Insightful)
90% of the driver code processes wireless frames. Saying that there is a vulnerability in the wireless driver when processing malicious frames provides zero information on an actual vulnerability.
Parent
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:3, Insightful)
It's trivial to catch Apple out - they can just release the communications they sent now that Apple have patched the drivers, and easily show Apple are lying when they said "They did not supply us with any information to allow us to identify a specific problem, so we initiated an internal audit."
Let's hear from SecureWorks now. Unless... this is a different issue... and Apple aren't lying in such as easily provable way.
Dell also released Wireless Patch (Score:3, Interesting)
Re: (Score:2)
Apple does not use the Intel wireless chipsets. They use atheros.
A near miss... (Score:2, Insightful)
12% of new laptops (Score:3, Interesting)
The "market share" dog don't hunt, coward.
Mac OS X wireless is not robust (Score:2, Insightful)
I know disabling SSID broadcast doesn't really give you much security, but I live in a townhouse. Why make it easy?
Re: (Score:3, Informative)
Re: (Score:3, Interesting)
But 99% of my headaches have been solved by simply adding networks I like to "preferred networks". Once I do that, all I have to do is "Turn AirPort On", and I'm connected.
And while I was travelling with my father, he was using XP, I was using OS X, and I could get on the hotel network in three clicks: wireless menu, Comfort Inn (or whatever), then click "yes" to the agreement from a web browser. It took him a bit more time, and my mother's computer can
Re: (Score:2)
Some more interesting Links (Score:4, Informative)
As always, daringfireball.net has an interesting article on this [daringfireball.net]. And The Macalope [macalope.com] chimes in, too, with a link to an article by Glenn Fleishman [wifinetnews.com]. Enjoy.
I don't think there's much of a story here. (Score:3, Informative)
I bought a Macbook Pro recently, and it does still have its share of problems. First of all, it's a new platform for Apple so it's almost bound to have a few issues that they didn't predict. Just because OSX has really been running for years on Intel platform, doesn't mean it's optimized for it yet.
This wireless patch deals with a couple of issues they've found. I installed the patch last night, and I sincerely hope that it does fix the "beachball of death" wireless issue that seems to have hit a fair number of MBP owners myself included. The wireless is pretty damned good, the antenna in the machine is significantly better than my other Dell laptop. However, it's not perfect, and it's known to cause problems in the right (wrong?) circumstances. I can't nail down precisely what those circumstances are, but it will freeze Finder with SBOD problems. Thankfully, EscapePod comes to the rescue for me or it would be that big fat power button of death for my MBP.
I reiterate... I am a Mac owner and I'm proud to say that Apple is at least proactively fixing their code. Secureworks identified one problem, Apple fixed three. That speaks volumes to me about how serious Apple are about squashing bugs.
Easy for Secureworks to prove their exploit now (Score:3, Insightful)
Re:Medical Marijuana (Score:5, Funny)
What did you expect? Were you hoping for your Mac to suddenly start playing band music, move confetti across the desktop, and then pop up the words "CONGRATULATIONS, YOU HAVE A PENDING PATCH AVAILABLE" over whatever you were trying to work with?
...
I wish Windows did that. :(
Parent
Re:what gets me... (Score:4, Insightful)
To a degree yes. You, nor anyone else in the world is willing to pay what it costs for a fully secure system. It costs money, but more than that it costs time, and people don't want to wait. It is possible to design perfect and bug free software with no defects or attack vectors, but the costs and time associated with it would put it out of the price range of even the most succesful of corporations. And in the end, it would be worthless because it would be outdated by the time you released it. So people want it now, which means not testing for some of the more fringe cases. They also want it cheaper which means leaving out more testing. Witness the computers of today vs the ones of yesteryear. Many computers years ago were built to last, in part because they were expensive enough that a company needed to make them a good investment. These days no one has the stomach to pay for a $5,000 personal computer, even if it means better build quality. They want the latest, the greatest, and they want it now. Software is the same way. We want the latest and the greatest and we want it now, to hell with perfection we can iron the bugs out later.
Parent
Re:what gets me... (Score:4, Insightful)
So let's say you accomplish near-perfection in your code, and you have 1 bug in the entire program. Now, put that program on an operating system, made up of thousands of other binaries, each with only *1* bug in them. Individually, each one of those binaries is nearly perfect. Taken all together, you have a buggy, quirky, unpredictable system of interactions. So do you not release your software until everybody else in the universe also gets theirs right?
Or do you just do the reasonable thing -- release it when it's "okay" so people can use it, and continue improving it via some patching or update process?
Parent
Knowing where to look. (Score:2)
This is important. The compiler telling me "Error on line 176: Expected semicolon" or something similar, even if the actual semicolon should go on line 159, is a hell of a lot better than "Whoops! Error SOMEWHERE in your 10k lines of code. Have fun!"
So, someone telling
Re:what gets me... (Score:5, Insightful)
It's like microwave popcorn. You nuke it and in the first few minutes you can get almost all of the kernels (exploits) popped. Then the rate of popping slows down. After a while, you simply have to stop or else you'll burn right through your profit (of warm, yummy popped corn).
And that's just not worth it. No matter what there will always be a few hiding way down in the bottom of the bag. You can burn through the whole thing and still never pop them all.
Parent