So Apple issued an update for the Mac wireless drivers to prevent a buffer overflow, but denies SecureWorks provided them anything useful.
Right. We believe you. Got it. You “just happened” to discover exactly the kind of vulnerability that Maynor and Ellch demoed, but they were evil, uncooperative bad guys for hinting they might be there. Considering SecureWorks works responsibly with all sorts of other vendors in the market I suspect the anger may be a tad misplaced.
Come on Apple; all software has vulnerabilities. It’s time to stop putting PR in charge of vulnerability management.
To quote the Macworld article linked above:
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. 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.” According to the update issued by Apple, 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.
It seems Apple also found some flaws in PowerPC systems, not just Intel Macs. At least the research spurred by Maynor and Ellch’s Black Hat/Defcon disclosures is improving security across the entire Mac product line.
But seriously- stop the security PR game or you’ll end up like Microsoft a few years ago…
edited 11pm : just want to state that based on additional information I believe it’s quite probable specific vulnerability details, especially on PPC, were discovered independently via Apple’s internal audit. My criticism is of the vitriolic handling of the situation when I believe this could have been resolved more quickly and responsibly had Apple played less with PR, and more with the researchers who obviously found something.
Reader interactions
10 Replies to “Sore Apples- Apple Updates Mac Wireless Drivers (With Prejudice)”
Recent events indicate that Apple may stay on an impossible message (perfect security) and face failures in capability despite the best intent. The entire Black Hat debacle showed Apple pushing the message so hard that the debate lived far longer than needed, exposing more of the public to a potential security failure than would have otherwise noticed, drawing the attention of researchers who may now want to prove Apple isn’t invincible, and losing the trust of some of us in the industry disappointed by PR’s management of the incident.
Rich:
Thanks—this will clearly go as a case study on how NOT to handle a newly discovered exploit— your moderation on this volatile subject is much appreciated
I just can’‘t talk about some of the questions you’‘re asking (Matt, rarhens, bkwatch).
What I can say is there are some weird twists, and I still feel comfortable reading and trusting Brian Krebs’’ reporting. Hopefully more of the truth will emerge over time, some of the twists are seriously weird and directly created all the hubbub.
Here is my main problem with the whole situation. Krebs of the Washington Post reported that Maynor and Ellch showed him hacking the internal wireless card on a Macbook. However, they failed to do so in the demo, which is understandable if they want to protect Apple.
What makes no sense is that they failed to show Apple the hack of the internal card. That’s very irresponsible behavior for a security company. You show an exploit to a newspaper reporter, but not to the company who makes the computer. That doesn’‘t seem like the work of a security company to me. It sounds like the work of a teenage hacker bragging to his friends. That is why people are doubting their claims. It makes no sense to do it and then not show Apple the results.
Also, as has been pointed out on other blogs, the patches address flaws different than the flaws exploited by Maynor and Ellch.
Rich:
I’‘ve decided to cook the crow with some fresh basil and rosemary. A nice chianti will help it go down.
The reverse shell was confusing. I’‘d have to check my notes. I think they mentioned it is their first interview with Krebs, but perhaps did not in the video. Perhaps they assumed it would be understood by the Blackhat crowd, but when the video entered wider circulation it caused a lot of confusion…
But the bit about the second wireless card: How do you explain Brian Krebs continuing to insist he saw the demo done with only the internal airport card. That one fact alone has been the source of the continuing rritation.
Yeah, a sentance or two, maybe to divulge that they were definately using two cards, and why, instead of stating specifically that the internal card was not being used. That was when he placed the third party card into the usb port, explaining why they were using it.
And they could have refrained from making disparaging remarks to the reporter about Mac users. THAT one kinda poisened the whole atmosphere, dontcha think?
I also think that a lot of this has happened due to the youth and inexperience of the two researchers. Either they didn’‘t get much guidance from their supervisors, or they didn’‘t listen, or they weren’‘t being watched. More experienced researchers may have been more aware of how their demo would be taken, and would have known not to make insulting off the cuff remarks to a reporter without making sure that it was off the record too.
Hopefully, the next time, they’‘ll be a bit more careful…
They did state, but not as clearly as they could have, that the second card was used just for demo purposes In a real attack they could drop code into the kernel to call back after the wireless process restarts. They explained that on stage, but it wasn’‘t well covered in the video. The attack was straight, but the method of demo wasn’‘t- thus creating confusion.
I’‘ve taken similar shortcuts myself during hacking demos since certain exploits don’‘t visualize well, or are really hard to do consistently. I do explain why I’‘m taking those shortcuts or are showing that way. For example, when I hack WPA on stage I use a “cooked” dictionary file to speed up the brute force.
I agree another sentence or two in the video would have cleaned some of this up.
I did watch the video, and they never claimed to be using the built-in card; as a matter of fact, they stated that the reason they were using the third party card was to NOT expose the built-in! So the fact that, as revealed in later posts, by Elch, I think, that they actually had to use BOTH cards to make it work, exposes the fact that the original demo was staged.
I never said that they didn’‘t hack it, I said it was staged and altered so it would look like a straight attack, against the third party card, when in fact, they had to use BOTH cards, since the attack actually crashed the first card, and the target had to reconnect using the second card.
Not what the demo said they were doing. That’s why people “hammered” them. Not for revealing a vulnerability, but because the demo didn’‘t make any sense, especially after the high-res version of the demo was examined.
Thus my statement that the demo was “cooked”. because it was, real or not.
And you’‘ll notice I didn’‘t say the built-in wasn’‘t vulnerable. Never, not once. Others may have questioned it, but that was because the demo was so unclear.
Yes, they DID claim that the built-in was also vulnerable, at least in the interview transcript from Brian Krebs. Not that it mattered, really.
also also note: If you want to get bent out of shape over the way Apple or Secureworks handled this, great! Vendor/Researcher relations is a different matter, and to me – more “impractical” to our jobs than a working definition of vulnerability
Actually, go watch the video- the explicitly state they are using 2 cards and attacking the third party wireless card, not the native Mac drivers. They never, in that presentation, claim that the native drivers are vulnerable.
Go to Toorcon and see the live demo for yourself, no need to trust me. The demo against the third party card was real.
As for the native wireless we now know it’s also vulnerable, so it’s not just the third party card.
I agree the press hype created far more problems than just doing the initial demo would have. As a blogger on this issue I’‘m probably part of the problem, but I felt the researchers were getting a bum rap- especially when people started hammering the video demo which was a real demo of a real vulnerability in a third party device drive running on a Mac (not a vulnerability of Apple code at all, and they didn’‘t claim that).