Wednesday
Sep062006
Proposal To Resolve Apple/SecureWorks Deadlock
Sep 6, 2006 at 10:57PM Dave G.
You may not have been aware, but there's been a lot of commotion about a potential vulnerability in the MacBook wireless driver (I have a dry sense of humor). For a change of pace, rather than discuss right vs. wrong, I'll propose a way for Apple and SecureWorks to end the stalemate.
Assume for a moment that Matasano is arbitrating. Here are our recommendations:
BOTH parties should:
SECUREWORKS should:
APPLE should:
Assume for a moment that Matasano is arbitrating. Here are our recommendations:
BOTH parties should:
- Call Off The Dogs: Get PR and Legal out of the way. The details are going to come out. Lawyers won't make them look better.
- End Radio Silence: From now on, as things move forward, BOTH parties should publish where they're at in the process. The Public needs a sense that things are actually moving forward. Neither party needs to reveal details; just evidence of progress (or lack thereof).
SECUREWORKS should:
- Notarize: SecureWorks is in possession of a collection of "proof-of-concept" documentation. Tar it up, sign it with a published GPG key, and SHA1 the bundle. Post the hash to the SecureWorks website. SecureWorks claims the vulnerability, eliminates any chance of someone else taking credit, and documents a date they can prove they knew about it. Like many of the good ideas we hear about, this one is derived from something Dave Aitel said.
- Hand Off: The very next thing that needs to happen is for both parties to state that the the proof-of-concept documentation (code, crash dumps, panic logs, and traffic captures) has been handed off. The vulnerability hasn't been fully disclosed until Apple absolutely has enough information to determine where, and what, it is.
APPLE should:
- Validate: Use the research SecureWorks provides to prove or disprove the finding.
- Confirm: Report those results back to SecureWorks.
- Patch, for the love of God, if the findings are valid.
- Release The Hounds! Apple needs to review all driver source code looking for similar problems. I am sure APPLE PR NEVER wants to hear the words 'Wireless Driver' and 'Security' ever again. As a Customer, I know I don't.
17 Comments | in Uncategorized 
Reader Comments (17)
Very generous of you to assume that both sides really have a dog in the fight.
I have an alternative solution: since information about potential bugs in Apple's drivers have been disclosed already (altho. not the technical details about them) you can asume that it is fair game to inspect the drivers yourself in order find the alleged bugs, what you do with the resulting information is entirely up to you and you don't depend on either side to end the stalemate. That's why third-party independent research is called "third-party", "independent" and "research" no?
If Apple and Secureworks can't find a way out of their deadlock, I am certain eventually somebody else will help them do it. http://www.xml-dev.com/lurker/message/20060818.220115.a3f014a4.en.html
all i can say is: hahahahha im so sick of hearing about this.. :) great post btw.. also
all i can say is: hahahahha im so sick of hearing about this.. :) great post btw.. also i bet someone else drop this so-called flaw..
Great idea, especially the fact about silence (Maynor has been too silent since bh)
Oh and agree on a better way to disclose vulnerabilities in the future
Apple seems to have an official policy of not publically acknowledging vulnerabilities, so I wouldn't hold my breath on that.
As for the proof of WHEN, I'm not that's even an issue in this case. Assuming that they have and exploit (and that is my belief, BTW), then Apple will eventually have to patch, and then SecureWorks can put out their advisory. For a reasonable person, they can trust that it was the one they demod at Black Hat.
Granted, not all intereted parties are reasonable...
Ivan:
That solves a different problem. This isn't just about some vulnerability. This is about defending research. Say someone finds numerous bugs in the driver and reports them. And let's just say they are of differing levels of exploitability or severity. SecureWorks would be in a position to claim that they found the most severe one even if they didn't. Please don't think I am attacking their ethics. I am just saying that, at that point, we would never really know what they found.
TomF:
Same here. Unfortunately, I don't think it's going away anytime soon...
Ryan:
I thought they had already said that the demo at Blackhat was absolutely on a 3rd party driver and not an Apple one. According to http://www.secureworks.com/newsandevents/blackhatcoverage.html:
This video presentation at Black Hat demonstrates vulnerabilities found in wireless device drivers. Although an Apple MacBook was used as the demo platform, it was exploited through a third-party wireless device driver - not the original wireless device driver that ships with the MacBook. As part of a responsible disclosure policy, we are not disclosing the name of the third-party wireless device driver until a patch is available.
See my previous comment on why I think When is still relevent here.
Ivan has an interesting idea, follow established principles of disclosure for peaceful scientific research. He makes this elegant argument in the above email link which I'll quote here:
> I have no intention to take sides in this
> discussion (I believe both
> SecureWorks and Apple could approach the issue at > hand in a more
> professional and effective manner) but I can't
> avoid to point out that
> this discussion would not exist if the common and > well-accepted
> methodology of modern science was followed:
>
> Researchers are supposed to document and publish
> their work; methodology,
> the specific conditions and assumptions and the
> results of their
> experiments so they can be scrutinized by their
> peers and other
> independent third-parties in order to verify the
> validity and implications
> of their work.
>
> If we really expect anybody to consider infosec
> research a serious
> profession based on scientific foundations we need > to be willing to accept
> and demand the practices of modern science when it > comes to research work.
As a researcher who has had to wait over a year in the past for patches to be issued by vendors, this approach to disclosure is really tempting. But in the end we don't see the latest bioweapons research being published in the New England Journal of Medicine. Lots of cutting edge research is done in this area, and there could be lots of crossover applications that could help modern medicine, but for obvious reasons people don't like the idea of a recipe for a doomsday virus being put into the hands of the public at large.
I'm not sure researchers can ethically publish the details of an attack for which there is no ready defense. If there is a ready defense in the form of a workaround, patch, or configuration change than it might be a different story.
In any case, lots of research companies decide not to publish the details of an attack for purely selfish reasons. Not every commercial entity that looks for new vulnerabilities intends to provide a public service.
Dave:
Yes, there is room to game the system in terms of when. I could claim that I have an Apache exploit, and just wait for the next patch as my "proof". In this specific case, I'm discounting that as a valid concern. I realize that some groups of people will NOT discount that possibility, but frankly, I'm not sure they can ever be satisfied.
As to who has to produce a patch....
They said in the Black Hat talk something like "this same kind of vulnerability affects the built-in wireless." (quoting from memory, apologies if I got it wrong.)
And then Johnny comes out and says that Apple has a patch coming in one of his DailyDave posts.
Since we're talking about off-the-cuff remarks, and not a carefully prepared statement, there is some leeway for them to not have quite meant it "that" way.
But yeah, I'm fully expecting an Apple patch that directly addresses something found by David and Johnny.
I put it on the other thread already, but my opinion-based counter-rant is here:
http://ryanlrussell.blogspot.com/2006/09/when-where-how-and-for-how-much-to.html
Dave's stated idea is good, perhaps the fine points need to be tuned, but for its worth persuing.
Anyone care to make a gentlemen's wager for or against secureworks? I'll put up a dozen donunts against.
Dave: Why does it solve a different problem? The problem to solve as I understood was: How to end the stalemate between Apple and Secureworks?. The answer was: Do the necessary research yourself, find out what the code says and draw your own conclusions, then you'll be in the position to solve it however way you like it.
On the defending research bit; Ok, but consider this. If you want me to defend your research then you have to convince me that what you're doing is research. You may choose not to convice me but then don't expect me to defend you as a researcher (I may however defend you as a great guy, good friend or free-willing individual but that's another story). It is also granted that my view for what constitutes 'research' may be different than yours and everybody else's. Does that make sense?
Josh: You make a good point there, but:
1- I call "analogy trap! analogy trap!"
vulnerability research is not biosciences, I am not saying it is better or worse or that it has higher or lower ethical or moral standards per se. It is just different and while different rules may apply to biosciences and vuln research, if you still want it to be considered it scientific research then some common basic scientific research guidelines should be followed: document it, publish it, have your peers validate your findings, help improve the general body of knowledge about your area of research.
2- If there is no ready defense because the vendor does not provide one and you don't provide one then the only remaining option that I can think of is to help somebody else to provide it. Disclosing details about the vulnerability is a viable step towards that end. And yes it does help would-be attackers too, but the underlying premise is that they need less external help to create their attacks than those attempting to create the defenses and that by disclosing information you are maximizing the odds that somebody else will find suitable, clever and/or ad-hoc defenses.
If the whole thing is about who gets credit for the findings the you are playing a PR game and the rules that apply to that scenario are quite different.
btw, to me "analogy trap" is when in the absence of a good rationale or explanation for a given event or phenomena in your discipline you decide or are
forced to use an analogy from a different discipline. If that happens is either because your discipline is not mature enough to explain the events that it deals with or because you are not thinking hard enough to find a good explanation within its context. The other option is that you are trying to simplify the explanation so people not versed in the inner workings, language and methods of your discipline can understand it. Anyway I am ranting already and for no good reason at all:)
All the answers are in the code so we just need to read them. Source code, binary, who cares... it's just bits after all.
It's a good proposal. But I don't think it will work as a solution to this mess. Maynor and Ellch triggered the bad PR through an apple-baiting title, a bad video, and talking to ill-informed reporters. The anger out there is now much less about what Maynor/Ellch discovered, but on improving HOW the issue is covered in the press. The utlimate end users -- or even businesses that buy information and software from security firms --are not always going to look in the code. I wouldn't suggest they look in ZDNET and the Washington Post either, but they will look to the specialtiy press to some degree.
Ivan:
Couple of counterpoints. Finding vulnerabilities in Wireless Drivers do not actually mean that you found what Ellch and Maynor found. This actually happened back when I was at KSR[T]. I was having problems writing an exploit, explained the bug to one of the other guys, and he sent me a working exploit for a different bug, thinking it was the same one.
In fact, *if* they haven't found a vulnerability (please don't construe that *if* as my opinion on the matter), then finding one only makes it easier for them to say that it was the same bug.
Not finding one also doesn't put you in the clear because Ellch and Maynor may be more clever then whoever is reading the code. How many people have looked at sendmail before Mark Dowd found the signal handling bug?
On defending research, I think the proposed way allows someone to defend their own research while their hands are tied by a political situation.
so, now I'm lost, are we talking about finding and fixing bugs or about getting credit for the findings? Personally I couldnt care less about who gets the credit or who claims to have found the most serious or "lame" bug, I just want to understand the problem and figure out how to address it if the vendor doesn't help me. Yes, finding new/different bugs on closed source software is not uncommon, specially since security advisories often disclose less vulnerabilities than what the patches actually fix and provide no technical details whatsoever, so you can't tell if what you find is what the patch addresses or if it is an entirely new thing. I have countless examples of this and a few other things (like simoultaneous bug finding), the latest example could be gera's recent post to bugtraq here
http://seclists.org/bugtraq/2006/Aug/0306.html
Announcing an all-new MCITP Examdesigned to help maximize your performance on 70-680 Exam, the required exam for the new MCTS: Windows 7, Configuration certification.This MCTS Exam includes the official Microsoft study guid
ed hardy hoodies
cheap christian audigier bikini
ed hardy shirts
cheap christian audigier hoody
women ed hardy clothing
ed hardy hoody uk
ed hardy jacket
ed hardy uk
ed hardy shirts
ed hardy swimwear
ed hardy ugg boots
ed hardy shoes uk
ed hardy hoody uk
buy ed hardy shirts
ed hardy womens shoes
ed hardy handbags uk
ed hardy at uk
ed hardy t shirts uk
ed hardy sunglasses uk
ed hardy womens tiger hoodie