Slashdot Mirror
Apple Patches Wireless Drivers
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."
For those that like details, here is more specific information on the patch: About the security content of AirPort Update 2006-001 and Security Update 2006-005.
Brian Krebs, at the Washington Post, has some additional background information and comments in his "SecurityFix" blog.
I'll let MacWorld say it for me:i ndex.php:
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."
The "flaw" that SecureWorks reported did not exist. Apple wasn't told what the flaw was or really any details about it, and like a responsible company, audited all relevant code irregardless. They found three potential *crashers*. These may be impossible crashers, as in the requirements to get to that section of code means it is impossible for the data to be invalid, but they added an error check "just in case".
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.
The flaw announced by SecureWorks was supposedly in a third-party wireless driver for MacOS, not Airport. The article says SecureWorks never gave any proof of a flaw in Apple's drivers, but that they audited them because of SecureWorks announcement and that these patches are the result.
Apple is still adamant that SecureWorks didn't find any flaws.
Actually .. there *IS* a flaw, as stated by Apple in the release, that does exactly what the SecureWorks people stated.
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.
"Don't worry about the problems you have in mathematics, I assure you mine are much greater." - Einstein c.1919
Maybe I don't understand your problem, but I have a WiFi network at home that does not broadcast its SSID, and uses WPA-PSK and MAC filtering for additional security. My PowerBook and PPC iMac both use this network, and I never have to type a password in. I added my home network to the "Preferred Networks" list in Network preferences.
Vote for global prefs bug
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.
Protoplasm. Quiet Protoplasm. I like quiet protoplasm.
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.
Just to correct the above, of the new patches (3 of them) only some are for the intel macs and some are for the ppc macs. Different flaws exist on different hardware configurations, one requiring 3rd party devices also.
"The use-mention distinction" is not "enforced here."
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?
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.
CVE-2006-3508 Available for: Mac OS X v10.4.7, Mac OS X Server v10.4.7
Impact: Attackers on the wireless network may cause system crashes, privilege elevation, or arbitrary code execution
Description: A heap buffer overflow exists in the AirPort wireless driver's handling of scan cache updates. An attacker in local proximity may be able to trigger the overflow by injecting a maliciously-crafted frame into the wireless network. This could lead to a system crash, privilege elevation, or arbitrary code execution with system privileges. This issue affects Intel-based Mac mini, MacBook, and MacBook Pro computers equipped with wireless. Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers are not affected. This update addresses the issue by performing additional validation of wireless frames. There is no known exploit for this issue. This issue does not affect systems prior to Mac OS X v10.4.
CVE-ID: CVE-2006-3509
Available for: Mac OS X v10.4.7, Mac OS X Server v10.4.7 Impact: Depending upon third-party wireless software in use, attackers on the wireless network may cause crashes or arbitrary code execution
Description: An integer overflow exists in the Airport wireless driver's API for third-party wireless software. This could lead to a buffer overflow in such applications dependent upon API usage. No applications are known to be affected at this time. If an application is affected, then an attacker in local proximity may be able to trigger an overflow by injecting a maliciously-crafted frame into the wireless network. This may cause crashes or lead to arbitrary code execution with the privileges of the user running the application. This issue affects Intel-based Mac mini, MacBook, and MacBook Pro computers equipped with wireless. Power Mac, PowerBook, iBook, iMac, Mac Pro, Xserve, and PowerPC-based Mac mini computers are not affected. This update addresses the issues by performing additional validation of wireless frames. There is no known exploit for this issue. This issue does not affect systems prior to Mac OS X v10.4.
As always, daringfireball.net has an interesting article on this. And The Macalope chimes in, too, with a link to an article by Glenn Fleishman. Enjoy.
I'm just glad Apple is actually finding bugs in their own code and fixing them in a reasonable period of time.
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.