Apple Wireless Security Update

Dave G. | September 21st, 2006 | Filed Under: Uncategorized

Apple released the security update today. First things first.

GET YOUR PATCH ON

Ok, with that out of the way, let’s take a quick look at what was said in the press and the security update itself. This is going to be a long post and I apologize:

The Press

The internal audit came as a result of claims by a senior researcher at SecureWorks that said he had revealed a vulnerability in Apple’s MacBook wireless software driver that would allow him to take control of the machine. SecureWorks later clarified its position and said it had used a third-party driver and not Apple’s driver.
Why did they clarify their position if they were right?

  • Pro Apple Stance: SecureWorks didn’t find a vulnerability in OS X, and had to restate.

  • Pro SecureWorks Stance: Apple bullied them. Plain and simple.

“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.”

  • Pro SecureWorks Stance: Total cover-up. They reported the vulns and now Apple is claiming that they found the vulns on their own.

  • Pro Apple Stance: SecureWorks didn’t provide any/enough information to fix these bugs, so they were forced to go on their own. They even went and found bugs in other drivers.

AirPort

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, 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.

Alright. These are clearly not SecureWorks findings (unless they reported them quietly). They specifically called out MacBooks which aren’t vulnerable to these security vulnerabilities. These are serious. Very serious. They are probably somewhere in the Broadcomm specific portions of the driver if the MacBooks and Intel Mac Mini are unaffected, but the Intel iMac is.

CVE-ID: 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, 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.

If the previous was specific to Broadcomm, this is probably specific to Atheros.

Noteworthy parts of this update entry:

  1. No credit to SecureWorks.

  • Pro Apple Stance: They didn’t report any of these bugs.

  • Pro SecureWorks Stance: They didn’t like us so they didn’t credit us.

2. “There is no known exploit for this issue.” Would Apple really say that if SecureWorks had sent them the exploit? Does an exploit really exist? If SecureWorks had sent them an exploit, would they be foolish enough to say that they don’t know of one existing?

  • Pro Apple Stance: SecureWorks didn’t send Apple the exploit.

  • Pro SecureWorks Stance: Total lie.

Is this SecureWorks finding? What if they found something else? Are Mac users still at risk here?

SecureWorks can show what e-mails they have sent. There has to be one with a panic.log/crashdump, or sample code. Or at least a technical description explaining the type of malformed frame triggered the exploit.

SecureWorks should put an advisory up explaining that this particular heap overflow is the bug they reported. Cat’s out of the bag now. I really wish SecureWorks had done this.

This is the strangest disclosure situation I have seen in forever. The worst part is users get caught in the middle. Is it over?

Viewing 11 Comments

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus