Case in point: just this week, David Maynor announced he would publish the details surrounding his shrouded hack against Mac OS X wireless drivers that was originally announced last year, but withheld by Apple's NDA. From the Computer World article:
"Maynor will soon publish a second paper on [some unimportant website] explaining how to write software that will run on a compromised system" (boldface is mine)At what point does the "educational" go into the weaponization of an attack? And just exactly how does a "security researcher" fit into the overall economic structure of attack and defense?
David Maynor (picking on him because of current events), works for Errata Security, a security consultancy. From the company's website (no I won't link to it, find it yourself;) ...
"Errata Security is comprised of industry veterans that have been involved in almost every facet of cybersecurity. This team has made many of the headlines you have read including predicting new threats and attacker trends to development of cutting edge technology. If you need the best, Errata Security can do product testing to technical consulting and everything in between." (boldface is mine)So, let's see if we can figure out the economic process ...
1. Find some vulnerability in some widely used product.
2. Create a proof-of-concept and publish it to the world (preferably before sharing it with the vendor).
3. Use FUD (Fear, Uncertainty, and Doubt) to sell the services of a security consultancy startup.
4. Profit!
The ethics employed here can best be explained by the little diagram I whipped up below. Imagine we (society or the world) can quantify all known and unknown vulnerabilities that existed yesterday, exist today, and will exist tomorrow-- that's the blue outer circle. Then imagine we could quantify all of the vulnerabilities known by adversaries (again: past, present, and future)-- that's the red (sort of "cranberry") circle. Imagine that we can quantify all of the vulnerabilities these obviously altruistic "security researchers" find for us-- the yellow circle. At some point, the subsets of vulns known by bad guys and good guys must overlap-- that's the idea where we have thwarted the bad guys and they must introduce new tactics to continue being adversarial.
The notion that folks, like Mr Maynor, follow is that if they make the yellow circle big enough, it will eclipse the blue circle and then there will never be a vulnerability (nor a security incident for that matter) ever again. Yet, those with solid foundations in security (as well as common sense) will realize that security is a social problem and not a technical one-- people will find ways and this may not be a finite calculation.
The second notion often heralded is that if we just make the yellow circle eclipse the red ("cranberry") circle, then we'll all be secure. Well, in theory, if the "good guys" knew all of the avenues for attack the "bad guys" know, then yes, perhaps, we would be pseudo-secure for a day or so. But there are two problems with this philosophy: 1) that is a daunting task, and 2) how do we know that the attacks we are finding are really truly overlapping with the attacks the bad guys know? What if the picture looked more like this (below)? What if our rockstar "security researchers" are really just finding new bugs that the bad guys won't ever find on their own? And, most importantly ... what if the bugs these "security researchers" find that the bad guys don't find end up being used by bad guys to attack the good guys' systems because the patch takes effort, energy, time (and sometimes politics) to deploy?
Wouldn't it be nice if these rockstar "security researchers" were out building systems that didn't have the bugs that other rockstar "security researchers" would eventually find? Wouldn't it be nice if they participated in the "build security in" mentality and lifecycle?
It would have been nice if Mr Maynor worked for Apple (either as an employee or a contractor) and helped with their design, implementation, and quality assurance prior to this buggy code being released to market. I certainly would have tenfold more respect for him in that scenario.
...
I will admit that there are a few researchers approaching rockstar status that don't appear to have such flippant disregard for the public at large. Some of them are taking the approach of doing what they are doing because they are "keeping vendors honest". I still question their motives from time to time (as anyone should). I'd list names here of ones whose goals I would support, but I cannot control those people and they fly so close to the sun.
Characteristics of reputable security researchers to watch for are: publication of generalized threat models, not specific exploits; the suggestion and proof-of-concept of solutions to problems, not just examples of problems; and, no apparent willing interest in taking the almighty dollar in exchange for their 5 minutes under the press spotlight.
3 comments:
I misread you article at first; I assumed by "find" you meant "find out about", not "find first".
I think there's a useful distinction to be drawn here; for vulnerabilities derived from implementation bugs, the number is definitely finite. Of course someone may use code in a new way, like using email to spam people, which can be considered a design flaw and not an implementation flaw.
The question of what is a vulnerability really is a matter of claimed security properties. If the author states that one property is that nobody will be able to do FOO, then if they can, it's a vulnerability. Of course nobody thinks this hard, or makes these claims. Absent such a claim, the author can just say that that property (e.g. being able to process input controlled by an opponent without giving him complete control over the system) wasn't a security property they intended to have.
As to whether they are participating in building secure products, I am no rockstar, but I do and always have considered myself a security researcher. I certainly learn from the other researchers, and use that knowledge to write better code, and I've never written a single exploit (see my web page). Yet without 2600, phrack, securityfocus, DEFCON, Black Hat, etc., I'd be very ignorant indeed. To have someone equate "security researchers" with "exploit writers" is frustrating to me, and many other responsible researchers. I realize you feel that many exploit writers use "security researcher" as a euphemism, but I feel it is accurate. If you're going to spread ill will, at least specify your target to reduce collateral damage.
Ideally yes, nobody would choose to do bad things, but absent that I'd rather know about the threats than not be able to know about them. When people go around implicitly defining "hacking" sites as evil or bad, they end up on content filters, and I end up not being able to even find out what the threats are. How am I supposed to defend against them if I can't visit the web sites?
They are neither good nor bad, just like studying martial arts doesn't make you good or bad; it's how you use it. I'm reminded of how Shaolin teachers used to teach Kung Fu; they teach young people some very complicated moves, many of which are superfluous, and years later, when the person has gained confidence through sparring and discipline and self-control, they explain the purpose of the actual move, and the student realizes they have been practicing it for years.
Hi Travis H,
Thanks for commenting.
What I am trying to get at is why a "security researcher" exists at all in an independent form. I understand that large, serious organizations will want to have security reviews of COTS (commercial off the shelf) products, but the people they hire for the "review" are typically direct employees or reputable consulting firms (firms whose reputation is based on client lists, not hype, or l33t h4x0r names). So why are we giving these other people any attention?
I'm all in favor of discussing design problems. It's the implementation bugs that are either (best case) redundant or (worst case) the impetus of a malware outbreak.
Now talking about why implementation bugs keep happening over and over again, now that might be interesting. Hence discussions of tools like static analysis, threat modeling, manual code reviews, fuzz testing, OS and Memory architectures, etc., are very valid. Talking about how person A found a bug in app B which caused payload C to ... well, that's worthless at best.
The reason independent researchers exist is that there is a lack of concern by large corporations in regards to secure code (industry wide, sure there are a few examples of companies that care – some). They are more interested in adding features, and getting the product ready on time. Security falls to a lower priority level under these circumstances. This has allowed numerous vulnerabilities to exist. Criminal minded, technically savvy people have been exploiting, so called, zero days for a long time. The independent security researcher is someone who is interested in bringing these to light, despite corporate neglect of the issue.
Post a Comment