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.
Apple quietly released a pair of patches today to its wireless drivers.
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.
The theory of relativity doesn't work right in Arkansas.
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."
Fucking hipocrisy
Welcome to Slashdot.
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.
"Apple quietly released..."
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?
"Sufferin' succotash."
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. :(
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
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.
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.
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.
Does Hipocrisy have a sister?
Cause I've been fucking Hypocrisy for years now.
Just thought they might be related.
Cause of the names you know.
[Fuck Beta]
o0t!
Speaking as someone who did five years at Apple, the company certainly does audit stuff before it's released -- particularly network and filesystem code. Patches and bugfixes also tend to get code-reviewed right inside the bug report by several people outside of the core group with good security experience, and reviewed again before they make it into a release. The main problem is that there are so many lines of code and only a finite amount of time, and the more subtle problems take longer to detect. There is a cost-to-profit tradeoff after a certain point.
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.