Login  |  Register  |  Contact

Hacking

Tuesday, September 05, 2006

Mac Wi-FI: Gruber Needs to Let It Go (and Maynor and Ellch Should Ignore the Challenge)

By Rich

Last Friday I was packing up for a weekend trip with my wife to Tuscon when my faithful RSS reader chased me down with the latest post on Daring Fireball. I ignored it over the weekend, but think it’s time for a response.

John Gruber, ever the poker player (his words, not mine) issued an open challenge to Dave Maynor and John Ellch to crack a stock MacBook. If they win, they keep it. If they can’t break in, they pay Gruber the retail price. Today John Gruber followed up with this post, upping the ante a bit and explaining why he feels this is a fair challenge. Adding to the data stream, John Ellch broke silence and released some details of a similar exploit using Centrino drivers (now patched) to the Daily Dave security mailing list.

First some full disclosure of my own. I’ve been a fan of Daring Fireball for some time, John and I share a mutual friend, and we’ve traded a few emails over this. But I really wish he had handled this situation differently. I respect John, and hope this post isn’t taken out of context and used for flame bait.

Now, why do I think Gruber is making a mistake? Because his challenge is putting good people in bad positions, it isn’t necessarily good for security, and he isn’t playing for the right stakes. Maynor, Ellch, and the security community in general should just ignore the challenge.

Check out the original post, but John challenges Maynor and Ellch to take a stock MacBook with a basic configuration and delete a file off the desktop via remote exploit. John’s reason for the challenge?

As for the earlier analogy to poker, I’m no fool. I don’t expect to lose this particular bet — but I don’t expect to win it, either. I expect to be ignored. I don’t think Maynor and Ellch have discovered such a vulnerability in the default MacBook AirPort card and driver, and so, if I’m right, they certainly won’t accept this challenge. I think what they’ve discovered — if they’ve in fact discovered anything useful at all — is a class of potential Wi-Fi-based exploit, which they demonstrated on a rigged MacBook to generate publicity at the expense of the Mac’s renowned reputation for security, but that they have not found an actual exploit based on this technique that works against the MacBook’s built-in AirPort. If I’m wrong, and they have discovered such a vulnerability, they may or may not choose to accept this challenge. But it’s a bet that they’ll only accept if they can win. It comes down to this. If I’m wrong, it’d be worth $1099 to know that MacBook users are in fact at risk. And if I’m right, someone needs to call Maynor and Ellch on their bullshit.

John’s challenge is misplaced and he should drop it. Why?

  1. I know the demonstration from Black Hat is real. Why? Aside from being at the presentation I had a personal demo (over live video) or exactly what they showed in the video. I got to ask detailed questions and walk through each step. Maynor and Ellch haven’t bullshitted anyone- their demo, as shown in the video and discussed in their presentation, is absolutely real. End of story. Want to see for yourself? Read to the end and you’ll have your own opportunity.
  2. Using the third-party card for the demo is responsible: Why? Because their goal was to show a class of attack across multiple platforms without disclosing an unpatched vulnerability. By using an anonymous card no single platform is exposed. Why the Mac? Because it demonstrates that a poorly written device driver can expose even a secure system to exploit. The third-party card highlights device drivers, not the OS, as the point of weakness. They could have shown this on Windows but everyone would have assumed it was just another Windows vulnerability. But the Mac? Time to pay attention and demand more from device manufacturers.
  3. Responsible disclosure encourages staying silent until a patch is released, or an exploit appears. Why? If responsibility, protecting good guys, or potential legal issues aren’t good enough for you just understand it’s the accepted security industry practice. Some vendors and independent researchers might be willing to act irresponsibly, but I respect Maynor and Ellch for only discussing known, patched vulnerabilities. I won’t pretend there’s full consensus around disclosure; I’ve even covered it here, but a significant portion of the industry supports staying silent on vulnerabilities while working with the vendor to get a patch. The goal is to best protect users. Some vendors abuse this (to control image), as do some researchers (to gain attention), but Maynor and Ellch staying silent is very reasonable to many security experts. Remember- the demonstration was only a small part of their overall presentation and probably wouldn’t have ga ered nearly as much attention if it weren’t for Brian Krebs’ sensationalist headline. That article quickly spun events out of control and is at the root of most of the current coverage and criticism.
  4. Just confirming an exploit could hurt Maynor and Ellch: Two words: Mike Lynn.
  5. This is between Maynor, Ellch, SecureWorks, and any vendors (including Apple) they may or may not be working with. I like Daring Fireball, but SecureWorks has a history of responsible disclosure and working with affected vendors, and I see no reason for them to change that policy to satisfy the curiosity of bloggers, reporters, or any other outsider.
  6. John’s stakes are too low. He’s asking Maynor and Ellch to bet their careers against MacBooks? If John puts Daring Fireball up as his ante the bet might be fair. Besides, Maynor already has a MacBook.
  7. This challenge doesn’t help anyone. At all. Is my MacBook Pro vulnerable? I don’t know, but even if it is there’s not a damn thing I can do about it until Apple issues a patch. It’s not like I’m turning off my wireless until I hear there’s some well-known exploit floating around. If Maynor and Ellch respond to the challenge all they do is satisfy people’s curiosity- it does NOTHING to improve security. If an exploit appears in the wild and Apple doesn’t patch they are free to disclose all the details they want per nearly anyone’s definition of responsible disclosure.
  8. Time will reveal all. Well, enough. I’m pretty confident all of John’s questions will be answered eventually. I think we’re far better served by letting the relevant parties work through this as part of a responsible disclosure process.

Let’s be honest- there are a lot of reasons Maynor and Ellch might not be willing to confirm or deny anything. Emergent Chaos has a good alternative. If, for any reason, Maynor and Ellch aren’t free to talk (which is pretty fracking obvious at this point) backing them into a corner doesn’t help anyone.

Still think they’re nothing but bullshit artists? Fine. Go to ToorCon and see for yourself. David Maynor has leaked that he and Johnny plan on doing some live demos on multiple platforms. Don’t expect to see any 0day exploit against any platform, especially a Mac, but you can at least satisfy your curiosity that these guys are the real deal, the third party demonstration was legitimate, and Maynor and Ellch are serious, responsible, researchers with other presentations under their belts. I’m sure they’ll walk you through the technical details.

Look, we all want to know if there’s some vulnerability in our Macs. There are. Plenty of them. Most of which haven’t been discovered yet. No operating system is immune to security vulnerabilities, but I’ve chosen Macs for me and my family because I consider them more secure than other platforms. Is there a wi-fi vulnerability on default Macs? Maybe, but I still plan on using my MacBook Pro at the local coffee house until I hear of some in-the-wild exploit.

Drop the challenge, John. Let any potential “interesting discussions” continue on their own. Just because they don’t want to validate something printed by a reporter doesn’t mean Maynor and Ellch are trying to attack Apple or pull a fast one on us Mac users. Escalating the situation helps no one. Maynor already apologized at Defcon, in front of probably a thousand or more attendees, 2 days after Black Hat, that the trash-talking-Mac quote in Krebs’ article was nothing more than joking around off the record, and never meant for publication. Calling these two liars and personally attacking them without validating through anything other than newspaper reports and blog posts isn’t close to fair.

My challenge to you? Go to ToorCon. Watch the presentation. Ask questions. You probably won’t learn if your Mac is vulnerable, but you will learn these guys know what they’re talking about.

–Rich

Tuesday, August 29, 2006

The 3 Dirty Little Secrets of Disclosure No One Wants to Talk About

By Rich

As a child one of the first signs of my budding geekness was a strange interest in professional “lingo”. Maybe it was an odd side effect of learning to walk at a volunteer ambulance headquarters in Jersey. Who knows what debilitating effects I suffered due to extended childhood exposure to radon, the air imbued with the random chemicals endemic to Jersey, and the staccato language of the early Emergency Medical Technicians whose ranks I would feel compelled to join later in life.

But this interest wasn’t limited to the realm of lights and sirens; it extended to professional subcultures ranging from emergency services, to astronauts, to the military, to professional photographers. As I aged and even joined some of these groups I continued to relish the mechanical patois reserved for those earning expertise in a domain.

Lingo is often a compression of language; a tool for condensing vast knowledge or concepts into a sound byte easily communicated to a trained recipient, slicing through the restrictive ambiguity of generic language. But lingo is also used as a tool of exclusion or to mask complexity. The world of technology in general, and information security in particular, is as guilty of lingo abuse as any doctor, lawyer, or sanitation specialist.

Nowhere is this more apparent than in our discussions of “Disclosure”. A simple term evoking religious fervor among hackers, dread among vendors, and misunderstanding among normal citizens and the media who wonder if it’s just a euphemism for online dating (now with photos!).

Disclosure is a complex issue worthy of full treatment; but today I’m going to focus on just 3 dirty little secrets. I’ll cut through the lingo to focus on the three problems of disclosure that I believe create most of the complexity. After the jump that is…

“Disclosure” is a bizarre process nearly unique to the world of information technology. For those of you not in the industry, “disclosure” is the term we use to describe the process of releasing information about vulnerabilities (flaws in software and hardware that attackers use to hack your systems). These flaws aren’t always discovered by the vendors making the products. In fact, after a product is released they are usually discovered by outsiders who either accidentally or purposely find the vulnerabilities. Keeping with our theme of “lingo” they’re often described as “white hats”, “black hats”, and “agnostic transgender grey hats”.

You can think of disclosure as a big-ass product recall where the vendor tells you “mistakes were made” and you need to fix your car with an updated part (except they don’t recall the product, you can only get the part if you have the right support contract and enough bandwidth, you have to pay all the costs of the mechanic (unless you do it yourself), you bear all responsibility for fixing your car the right way, if you don’t fix it or fix it wrong you’re responsible for any children killed, and the car manufacturer is in no way actually responsible for the car working before the fix, after the fix, or in any related dimensions where they may sell said product). It’s really all your fault you know.

Conceptually “disclosure” is the process of releasing information about the flaw. The theory is consumers of the product have a right to know there’s a security problem, and with the right level of details can protect themselves. With “full disclosure” all information is released, sometimes before there’s a patch, sometimes after; sometimes the discoverer works with the vendor (not always), but always with intense technical detail. “Responsible disclosure” means the researcher has notified the vendor, provided them with details so they can build a fix, and doesn’t release any information to anyone until a patch is released or they find someone exploiting the flaw in the wild. Of course to some vendors use the concept of responsible disclosure as a tool to “manage” researchers looking at their products. “Graphic disclosure” refers to either full disclosure with extreme prejudice, or online dating (now with photos!).

There’s a lot of confusion, even within the industry, as to what we really mean by disclosure and it it’s good or bad to make this information public. Unlike many other industries we seem to feel it’s wrong for a vendor to fix a flaw without making it public. Some vendors even buy flaws in other vendors products; just look at the controversy around yesterday’s announcement from TippingPoint. There was a great panel with all sides represented at the recent Black Hat conference.

So what are the dirty little secrets?

  1. Full disclosure helps the bad guys
  2. It’s about ego, control, and competition
  3. We need the threat of full disclosure or vendors will ignore security

There. I’ve said it. Full disclosure sucks, but many vendors would screw their customers and ignore security without it.

Some of full disclosure originates with the concept that “security through obscurity” always fails. That if you keep a hole secret, the bad guys will always discover it eventually so it’s better to make it public so good guys can protect themselves. We find the roots of the security through obscurity concept in cryptography (early information security theory was dominated by cryptographers). Secret crypto techniques were bad, since they might not work; opening the mathematical equations to public scrutiny reduces the chances of flaws and improves security. As with many acts of creation it’s nearly impossible to accurately proof your own work [as my friend and unofficial editor Chris just pointed out].

But in the world of traditional security, obscurity sure as hell works. Not all bad guys are created equal, and the harder I make it for them to find the hole in my security system, the harder it is for a successful attack. Especially if I know where the hole is and fix it before they find it. Secrets can be good.

The more we disclose, the easier we make life for the bad guys. “Full disclosure” means we release all the little details. It used to be kind of tough to create an exploit from a vulnerability disclosure, but with new tools like Metasploit it takes far less skill than even a couple years ago. Exploits appear within hours or days of a vulnerability disclosure, not months. Conceptually it’s best if the good guys also know the details so we can harden our systems, make appropriate risk decisions; and so third-party security vendors can help protect us.

Whatever your position on full disclosure, and there are many good reasons for it, you need to admit that it helps the bad guys. There you go, just say it, say, “full disclosure helps script kiddies break into grandma’s computer”. It feels good, doesn’t it?

But without full disclosure many vendors would treat us like an Enron retirement plan. They’d hide vulnerabilities, avoid patching (since that costs money), and not share details with security vendors (some kids don’t play well with others). I wish it were otherwise, but we need the threat of full disclosure to help keep the vendors honest. I believe in market forces, but they only work on behalf of consumers when they’re informed. Some vendors just don’t get it, but I’ll behave and avoid naming them here.

And what about the researchers? Some are genuine do-gooders just passing on helpful information they discover as part of their job. But most vulnerabilities discovered by outsiders are used as leverage for a goal. For some it’s glory, others want access to a big product vendor, some want attention, others cash, and for security vendors it can be PR, competitive advantage, or blackmail. There is nothing wrong in wanting credit for your work, heck- I make my living getting attention- but if ego is your driver you need to constantly ask yourself if what you’re doing is for the common good or merely self enrichment. You security vendors also need some introspection- is your disclosure process a PR stunt or even blackmail to force clients to buy your service? If so you’re no better than the worst of the black hats hacking away in smoky Eastern European (or Lower East Side) bars.

I’ve worked with many responsible researchers and security vendors, but we all need to maintain constant diligence or risk crossing the line and hurting the public for self gain.

Disclosure is a simple term for an incredibly complex system of checks and balances. I won’t pretend I have all the answers; nor will I suggest, as others others deeper in the issue have, acceptable timelines and processes for disclosure. But I will suggest it’s time to bring more honesty and introspection to the debate. Only if we’re willing to strip away the subcultural lingo and admit the potential pitfalls and our motivations can we improve the process and keep grandma’s computer safe.

Even grandma needs a little online dating (now with photos!)…

–Rich

Monday, August 21, 2006

Another Take on the Mac Wireless Hack

By Rich

On Friday the Mac Wireless hack issue exploded again after Apple PR issued a carefully worded press release. Next thing you know one of my favorite sites, The Unofficial Apple Weblog posts a headline that’s just wrong.

There have been a lot of really bad posts on this topic, but John Gruber at Daring Fireball winds his way through the press and blog hype in a well reasoned article, The Curious Case of the Supposed MacBook Wi-Fi Hack. John’s reasoning is strong, but I believe we can take his assumptions in a different direction and finish with essentially the opposite results.

First some full disclosure- I was at Black Hat and Defcon, talked with Maynor and Ellch, and have followed up with Maynor and SecureWorks since the event. I won’t be revealing any secret information here, but will just analyze John Gruber’s assumptions and see how his conclusions might change. John and I also emailed a bit on this issue over the weekend (he’s on vacation this week, so might not be able to respond).

For those of you with short attention spans I believe that Maynor and Ellch will emerge with their reputations intact and have been trying to do the right thing from the start. If I’m wrong I’ll be the first to call myself on it and apologize, but I really don’t expect that to happen.

John’s first assumption is:

“What”s notable about this disclosure is that it is about the driver. We already know, just from watching the demonstration video, that it was also based on a third-party card. This means that either (a) the exploit they discovered uses neither the MacBook”s built-in card nor Mac OS X”s built-in driver; (b) the exploit they discovered works against both the third-party driver demonstrated in the video and against Apple”s standard driver, and they have inexplicably decided to post this disclaimer to explicitly describe only what is being demonstrated in the video; or (c) that the “experts” at SecureWorks do not understand the difference between a driver and a card. My money is on (a).”

Let’s explore option (b), especially the last part: ‘…they have inexplicably decided to post this disclaimer to explicitly describe only what is being demonstrated in the video’ . (bold added) I propose an alternative: that they purposely posted the disclaimer to explicitly describe only what is being demonstrated in the video. Why would they do this? Not all security researchers believe in full disclosure. If you are one of these researchers and you don’t want to disclose the details of an unpatched vulnerability but want to demonstrate the class of vulnerability (device driver exploits) you might choose to demonstrate the vulnerability using an unidentified device. In the background you would notify any affected vendors and give them time to respond. If you show the attack on the built-in wireless device you instantly identify the vendor involved. An anonymous third-party card avoids this exposure.

Let’s move to the next few points which focus on Brian Krebs. John states,

“The reason this is notable is that if (a) is true (that the vulnerability they discovered does not apply to the standard AirPort driver software from Apple) it entirely contradicts Brian Krebs”s original and much-publicized story. Krebs wrote (emphasis added): “The video shows Ellch and Maynor targeting a specific security flaw in the Macbook”s [sic] wireless “device driver,” the software that allows the internal wireless card to communicate with the underlying OS X operating system. While those device driver flaws are particular to the MacBook – and presently not publicly disclosed – Maynor said the two have found at least two similar flaws in device drivers for wireless cards either designed for or embedded in machines running the Windows OS. Still, the presenters said they ultimately decided to run the demo against a Mac due to what Maynor called the “Mac user base aura of smugness on security.”

Brian is a reporter and as such has different motivations than a security researcher. Brian posted this information and stands by it. Maynor and Ellch have followed a policy of not commenting on the potential vulnerability of native MacBook wireless drivers. Thus we have a situation where Brian reported something, but the sources won’t validate or repudiate the statement. Maynor and Ellch have yet to either confirm or deny Brian’s reporting. Why might they do this?

If the vulnerability was real and they didn’t wish to disclose it until the vendor involved issued a patch. For this to be true they would have to have informed Apple (and the anonymous third-party device vendor) and said vendor wasn’t ready, for whatever reasons, to issue a patch. Since we’re only a few weeks from the initial disclosure we’re still in a reasonable timeframe. Remember, if they confirm Brian’s post they thus release enough details on the vulnerability that it could be replicated. But they haven’t denied the statement, which either indicates it’s true, Brian is wrong, or they lied. I don’t believe this is something they would lie about. Brian is now in the unenviable position of trying to justify his reporting without confirmation from his sources. While not a reporter (I’m just an analyst and blogger) I’ve come close to similar situations and they’re no fun.

Next we have to look at Apple’s official response. John states:

“In response to SecureWorks”s admission that their demonstration did not exploit the built-in driver, Apple on Friday released a statement regarding the supposed vulnerability. Lynn Fox, Apple”s director of Mac PR, told Macworld: “Despite SecureWorks being quoted saying the Mac is threatened by the exploit demonstrated at Black Hat, they have provided no evidence that in fact it is. To the contrary, the SecureWorks demonstration used a third party USB 802.11 device – not the 802.11 hardware in the Mac – a device which uses a different chip and different software drivers than those on the Mac. Further, SecureWorks has not shared or demonstrated any code in relation to the Black Hat-demonstrated exploit that is relevant to the hardware and software that we ship.” Fox”s statement on behalf of Apple is unequivocal: Maynor and Ellch”s exploit involves neither the MacBook”s standard Wi-Fi hardware card or software driver. That, of course, does not mean that Apple”s standard driver isn”t somehow similarly vulnerable, but if it is, Maynor and Ellch have not demonstrated such a vulnerability to Apple, according to Fox.”

But we can parse Apple’s statement a little differently. In their Black Hat/Defcon presentations Maynor and Ellch never identified any specific wireless device that was vulnerable. SecureWorks may have been quoted as saying that, but the only source is Krebs’ article (not the presentation or any official press release). They made an explicit decision, stated in the presentation, not to identify any vulnerable device/driver, and used an unidentified external card to support this decision. The only part that doesn’t make sense to me is that they have provided no evidence that in fact it is. This statement is supported by:

Further, SecureWorks has not shared or demonstrated any code in relation to the Black Hat-demonstrated exploit that is relevant to the hardware and software that we ship.”

John considers this an unequivocal statement that the exploit doesn’t involve the MacBook native wireless, but we can read this in a different way. Maynor and Ellch have “not shared or demonstrated any code… relevant to the hardware and software we ship”. For us in the security business this doesn’t mean there isn’t a vulnerability, it’s just a statement as to the level of detail given to Apple. You can exchange details of a vulnerability without sharing or demonstrating code. Apple only denied code was exchanged or demonstrated, they don’t deny the vulnerability.

Yes- we’re parsing words as finely as a politician here but if there’s one thing I’ve learned in 5+ years as an analyst it’s to never trust PR, no matter how respectable the vendor they represent it. Notice Apple has not made any formal statement that the MacBook (or any other product) is not vulnerable to this class of exploit? In my mind that’s a glaring omission. Apple could put this to rest with a single statement, but they haven’t.

As for Atheros it may be they haven’t been contacted directly. If this is a Mac specific issue on native hardware I would probably contact Apple first myself, so the Atheros denial (which I believe is true) doesn’t affect the overall argument.

John’s next section is the most essential to his piece:

This entire saga boils down to one simple question: Have Maynor and Ellch discovered a vulnerability against MacBooks using Apple”s built-in AirPort cards and drivers? Given all the facts laid out in the previous section, you might at first think this question has been answered, and that the answer is “no”, but unless I”m missing something, this is, inexplicably, still an open question.

It’s not inexplicable, but a potentially valid situation if we are dealing with an unpatched vulnerability that no one wishes to disclose until a patch is released.

John continues:

We do have enough facts, however, to know with certainty that some of our protagonists will not emerge with their reputations intact. Someone, clearly, is either lying or incompetent (or both)… …For example, from Apple”s statement on Friday, we know that if Maynor and Ellch have identified an exploit against a stock MacBook, that they have not yet contacted Apple (or Atheros) with details about the vulnerability – which is both enormously irresponsible for ostensibly professional security researchers, and which contradicts statements they previously made to Brian Krebs that they had been in contact with Apple regarding their discoveries. Or, if they have contacted Apple, the statement issued by Apple”s Lynn Fox is flat-out false and Apple has committed an enormous, almost incomprehensibly foolish mistake, because such a mendacious lie will prove far worse for Apple than divulging a Wi-Fi exploit that, if it actually exists, is surely going to come to light soon anyway. I.e. why would Apple lie about this if Maynor could call them on it?

As shown we may have totally valid reasons for both the actions of Maynor/Ellch/SecureWorks and Krebs. Apple has only stated no code was exchanged and that no demonstration has been shown against native Mac hardware/software. Apple’s statement can be true, Maynor’s statements true, and Krebs’ statements true. How?

1. Maynor and Ellch may be following responsible disclosure guidelines and refusing to validate the vulnerability status of any hardware/software. 2. Krebs may have either misheard or reported something Maynor and Ellch didn’t mean to expose. If true, and they neither want to lie nor expose the vulnerability and thus the best course of action is to neither confirm nor deny. 3. Apple may know about the vulnerability and for the same reasons not wish to expose that their platform is vulnerable. The statement from Fox can be true without denying the vulnerability. Considering how protective Apple is of the brand I could see this as a very real possibility.

If SecureWorks, Maynor, and Ellch are working with Apple they could easily be in the position of not even being able to validate what platform was used. Why? Because most people are forgetting what their Black Hat/Defcon presentation was about.

In the presentation Maynor and Ellch discussed the use of “fuzzing” to discover device driver exploits. Only a very small part of the presentation was devoted to the specific exploit in the video. They each described different techniques for fuzzing and the systems they used to explore wireless driver vulnerabilities. The actual Mac hack was just a short demo at the end. A knowledgeable attacker could use this very technique to discover/exploit similar vulnerabilities across a range of wireless devices. This brings us to John’s conclusion (I’m skipping sections on other responses we’ve seen on the web to focus on Maynor and Ellch):

The principle of Occam”s Razor holds that the most obvious explanation is the most likely to be true. By that guideline and the evidence at hand, it is my guess that Maynor and Ellch are disingenuous publicity hounds who studied a previously-identified vulnerability in a FreeBSD Wi-Fi driver and concluded that they could perhaps use this published vulnerability against Mac OS X. I think they tried – and failed – to find an exploit that works against the standard AirPort cards and drivers used by nearly all Mac users, and that they then realized they could, in a demo, exploit buggy drivers other than Apple”s on a doctored MacBook and draw much more attention to themselves and their firm than if their demo had been performed on any other computer, using Windows or an open source operating system. I believe the “informed” Apple about a FreeBSD wireless driver issue that Apple already knew about, so that they (i.e. Maynor and Ellch) could honestly claim to have approached “about a I.e. that despite the fact that the exploit they had discovered is completely and utterly irrelevant to anyone using a MacBook with Apple”s default AirPort driver and card, which is to say all MacBooks other than the one that Maynor and Ellch modified specifically for their contrived demo, they chose to perform their demo using the MacBook.

Or, they discovered a related vulnerability as part of their research on fuzzing to expose device driver exploits. Trying to be responsible they don’t want to disclose the platforms involved until patches are released and used an unidentified third-party card. The BSD vulnerability might have shown them an avenue for research, but their presentation supports the position that their goal wasn’t to crack a single device, but to show new techniques for exposing a class of vulnerabilities. Unfortunately very few bloggers/reporters were in the presentation to see this.

John ends with:

Now that the “fireworks” are starting, my guess is that Maynor and Ellch, if they choose to defend themselves rather than quietly walking away from the table, will do so by claiming that they never stated nor implied that they had found any vulnerabilities in the MacBook”s built-in card and driver. But their prevarications were far too clumsy for them to get away with this. It is a simple yes or no question: Have Maynor and Ellch found a vulnerability that affects MacBooks using Apple”s built-in cards and drivers? That Maynor and Ellch haven”t answered it speaks volumes. Bring on the fireworks.

John’s totally correct- one option is they can come out and state they never claimed native drivers were vulnerable. In that case then the only person at fault is Krebs in his blog. But there’s another option- Apple could release a patch or Maynor/Ellch could release details (or both at the same time). Then everyone is right, although Apple PR doesn’t come out as well.

I think John has, by far, the best analysis of this situation but it leads me to a different conclusion. I can see how in the process of being responsible and of working with Apple that Maynor and Ellch would keep quiet as the fireworks start.

I don’t know how this will end up. I don’t know what will finally be released (or not). But using only John’s own analysis (and the fact I saw the original presentation) I can easily see Maynor, Ellch, SecureWorks, and Krebs emerging with their reputations more than intact.(edited 8/22 to clean formatting)

–Rich