X
Business

Apple strongly denies getting information from SecureWorks

I posed some questions to Apple when I wrote "Apple patches Wi-Fi but refuses to give researchers due credit" to try and pin down exactly what Apple acknowledges to have received from SecureWorks or not. I was a bit surprised when I got all of them answered based on my past experience so I will have to give Apple some credit for not dodging any of the questions this time and answering in a straight forward manner. The answers also surprised me since this puts Apple and the two security researchers David Maynor and Jon Ellch on a collision course at Toorcon 2006 and there is no backing out at either end.
Written by George Ou, Contributor

I posed some questions to Apple when I wrote "Apple patches Wi-Fi but refuses to give researchers due credit" to try and pin down exactly what Apple acknowledges to have received from SecureWorks or not.  I was a bit surprised when I got all of them answered based on my past experience so I will have to give Apple some credit for not dodging any of the questions this time and answering in a straight forward manner.  The answers also surprised me since this puts Apple and the two security researchers David Maynor and Jon Ellch on a collision course at Toorcon 2006 and there is no backing out at either end.  [Update 11:59 PM: David Burke gives a great analysis to the following response.]

Here is the word-for-word email response from Director of Mac PR Lynn Fox:

George,

Answers to your questions are below.

We noticed that there was a question on your blog for us that was not included in your below email (on packet captures), so we've also answered that question for you too.

• Did SecureWorks ever disclose any Wi-Fi vulnerabilities to Apple?

The only vulnerability mentioned by David Maynor was FreeBSD vulnerability CVE-2006-0226. This does not affect Apple products.

• Did SecureWorks ever disclose the packet captures of the malicious payload used to trigger said vulnerabilities?

No. Packet captures were promised repeatedly but never delivered.

• Did SecureWorks ever provide driver disassemblies pertaining to said Wi-Fi vulnerabilities?

No. While SecureWorks did provide a driver disassembly, it did not indicate a Wi-Fi vulnerability in any Apple product.

• Did SecureWorks ever provide crash dumps pertaining to said Wi-Fi vulnerabilities?

No. While we received crash dumps from SecureWorks, they didn't have anything to do with Mac OS X or any other Apple product.

• Did SecureWorks ever point to the location of the vulnerable code of said Wi-Fi vulnerabilities?

No.

• Do any of the current patches released by Apple match any of the characteristics of the information provided by SecureWorks?

No.

I'd also like to comment on this excerpt from your post:

"'Fox also said Apple staff were already aware of the flaw when SecureWorks contacted them about it prior to their Black Hat presentation, and that Apple had already determined that the wireless flaw addressed in the FreeBSD patch was not exploitable on any of the Mac products'

Now this statement has come back to haunt Apple. Ironically, I had accidentally stumbled upon this when I asked Maynor and Ellch in my video interview if the Wi-Fi vulnerability was anything "like" the FreeBSD hack back in January. I could have sworn I got a funny reaction from Maynor and Ellch but I figured they only reacted that way because not many people knew about the FreeBSD flaw. Little did I know at the time that I had actually stumbled upon the truth and that the Apple Wi-Fi flaw was EXACTLY like the FreeBSD flaw because it's all the same code."

The code flaws we addressed with the Wi-Fi security updates we released on September 21 are not based on the same code as the FreeBSD flaw.

We think this helps clarify what we've been saying all along and helps put this topic to rest.

Feel free to post my email to your blog word-for-word to avoid any confusion.

Lynn Fox

Director, Mac PR

Apple

Things keep getting more interesting every day.  More to come on this.

Editorial standards