the disclosure debate is the wrong argument

prompted by an exchange on twitter this morning i began spending mental resources on an old favourite that everyone loves (hates) to go over again and again - the disclosure debate.

the disclosure debate is a debate over what the right answer is to the question  "i found a problem, now what do i do with it?". it's a natural place to come from for many in the security community and the question surely needs an answer. but the disclosure debate tries to raise the answer into a principle and each side of the debate believes that their side is more principled, more virtuous than the other. you have to pick a side and in so doing you also pick a tribe and signal your allegiance.

the disclosure debate has been raging in the security community for a long time and the two major sides right now are full disclosure which is generally favoured by security researchers, and responsible disclosure which is generally favoured by vendors. when you pick a side you're choosing to align with one of these groups.

but is that really it? is it just a choice between researchers and vendors? are they the only ones with real skin in the game? hell no.

so then let's catalog the groups of people involved:

1. vendors of vulnerable products/systems/services. these are the people who, when faced with discovery of a security vulnerability in their product, are expected to act quickly and create a fix for their product to eliminate the risk posed by by that vulnerability
2. security researchers. these are the people who find the vulnerabilities. often a great deal of work goes into finding vulnerabilities and consequently researchers often want and even deserve some kind of reward, whether simply adding to their reputation which they can parlay into better paying job or a more direct financial reward like a bug bounty.
3. attackers. these are the people who would actually exploit the vulnerability to victimize people, whether for money, ideology, or a laundry list of other reasons
4. users of vulnerable products/systems/services, be they businesses, institutions, individuals, etc. these are the people who are actually affected by vulnerabilities and arguably should be the most important consideration

now attackers and users don't figure all that much in the disclosure debate. sure the ostensible reason we have the debate is because we say we want to help the users, and the reason for doing the vulnerability research and disclosing the results at all is supposed to be to thwart attackers, but when arguing over which side of the disclosure debate is best attackers and users are treated as constants, as monolithic homogeneous groups that always present the same issues in every case and that's just not an accurate reflection of reality. 

not all attackers would be able to find the vulnerabilities on their own. those that can are just as much a minority as the security researchers themselves are. not all attackers are interested in any given vulnerability. those that target foreign states may be more interested in PLC vulnerabilities than VLC vulnerabilities. some may not have the connections or resources to exploit a particular vulnerability. some may specialize in attacks against a completely different kind of technology. some are simply not motivated enough to add a new exploit to their arsenal.

meanwhile, not all users pay attention to the channels where disclosures are communicated, in large part because most users can't understand or meaningfully act on the information in a disclosure. filtering out attack traffic, using IOCs, deploying mitigations, etc. are all the domain of a very select group. additionally not all users are aware of all patches when they become available, or are willing or able to apply them.

these are only a fraction of the variations among the two groups that can affect if/how they'll use a vulnerability and if/how they might be affected by the vulnerability. the reason we keep having the disclosure debate is because that debate has never adequately addressed these variables, because they have the potential to make the answer change depending on the vulnerability, which would mean there is no single right answer or right side in the debate. the debate focuses on principles to the exclusion of nuance, only paying lip service to the people who would use the vulnerabilities and the people those vulnerabilities would be used against. 

those who find a problem in some kind of technology want an easy answer to the question of what they should do with it - that's why the disclosure debate exists, to try and arrive at an easy answer so people can just follow the one right principle for handling the situation and be done with it. it follows a trend that has become all too common in the technology sector of trying to abstract people out of the equation because people are messy and complicated. but people are part of the equation whether we like it or not so the argument shouldn't be about which principle is right, but rather whether our actions should be governed by principle or by considerations for people.

in the watchmen, the character rorschach was governed by principles to the exclusion of virtually everything else ("never compromise. not even in the face of armageddon"). defending truth and justice so stridently made him arguably the most heroic, in the comic book sense of the word. but the more realistic portrayal of individuals and circumstances and society as a whole in the watchmen highlighted how ill-fitting such unwavering adherence to principles can be in the real world.

we need to stop talking about the disclosure debate, not because it should be settled already, but because it can never be settled, because it's parameters don't fit the real world. it's the wrong argument. if we really want to help protect one group of people from another group of people then we need to spend a lot more time thinking about those people each and every time the subject comes up. there are no shortcuts when it comes to doing the right thing.

thoughts on attack automation

axiom: there is no perfect security

because there is no perfect security we can say with certainty that systems will never be perfectly secure. if we close one vulnerability there will always be another to take it's place. we can spend an unending amount of money/time/effort on closing vulnerabilities and still remain vulnerable. in the process of doing this we would go bankrupt because no one, not even the largest companies in the world, have unlimited resources to spend on security.

therefore, eliminating all the vulnerabilities is not a viable strategy. instead a promising alternative is to approach the problem of security from an economic standpoint. while we can't eliminate all the vulnerabilities, we can eliminate some, and if we eliminate the ones that are easiest to exploit then an attacker's job becomes harder and more expensive to carry out. if we make the attacker's job hard enough then the value/benefits they derive from succeeding in their attack (success will always be possible) would no longer cover the cost of launching that attack.

attack automation doesn't make an attacker's job harder. quite the opposite in fact, it makes it easier. attack automation is carried out by attack tools. as a general rule, attack tools reduce the complexity of performing an attack. tools automate the fiddly bits to save an attacker time and effort but in so doing also save the attacker from needing to know how to do the fiddly bits themselves. this means that a larger population of attackers will become capable of carrying out a particular attack because the technical complexity of performing the attack is reduced. it also means there is a larger pool of targets to victimize because the lower cost of performing the attack makes attacking lower value targets economically viable.

additional automation to save the attacker time and effort when selecting targets and launching attacks is also possible, as the recent release of autosploit has highlighted. this lowers the cost of scaling up the attack so that a single attacker can attack a larger group of victims at a lower cost.

the argument can be made that attackers are entirely capable of making these automated attack tools themselves so it doesn't matter if security researchers do it as well. however, when researchers make the automated attack tools, not only do attackers enjoy cost savings with respect to launching attacks, they also enjoy cost savings with respect to developing the tools to launch attacks.

all of these cost savings for the attacker work against defenders. when the cost of performing an attack is reduced it means that attacks that didn't need to be defended against before (because they were too expensive to launch relative to their payoff) must now be defended against, and that increases the costs for defenders because it requires more to be done.

these cost savings are also permanent. attacks don't get harder, they only ever get easier. offensive security researchers are permanently changing the economics of mounting various attacks in the attackers' favour in an effort to incentivize defenders to do what the researchers think should be done to chase after the zero-vuln goal (a goal which we already know to be unattainable) without regard to the economic realities those defenders face.

enforcing their will, their vision of what security should be on others is misguided and damaging. there is no one-size-fits-all approach to security, and where the fit is bad there will be undue burdens with respect to cost and/or unfortunate breaches that might legitimately have been avoided if attackers had not been given a helping hand.

if attackers can build the tools that make their lives easier by themselves, then let them do it. make them pay the cost of doing it. stop subsidizing attackers in the name of security research. years ago the security research community embraced the idea that there should be no more free bugs - why then are the cybercriminals still getting bugs, and exploits, and frameworks, and more for free after all this time?

disclosure options

kevin townsend drew my attention to this post on the google online security blog about responsible disclosure (should you read the post, pay special attention to the list of authors - if you've been paying attention to the disclosure debate lately you'll recognize one of the names). it discusses the fact that responsible disclosure sometimes fails to provide adequate motivation for software vendors to fix their code and how that actually puts users in danger because it means the vulnerabilities in question won't get fixed.

unfortunately the security folks over at google fall into pretty much the same trap that a lot of the security community falls into - the trap of binary thinking (i'm sure there's a loftier term but this will do). when we talk about disclosure many people only consider two main alternatives: full disclosure and responsible disclosure. in reality, however, there are additional alternatives between those two and even some beyond those two.

unless you're quite new to the security field or have been living under a rock these past couple of years you probably have heard of partial disclosure - dan kaminski famously used it for the DNS vulnerability discovered back in 2008. whatever your opinion of partial disclosure might be, it clearly highlights the fact that there are more than 2 options when it comes to disclosure. in fact, partial disclosure opens up an entire range of options depending on how much information you disclose. the number of options for partial disclosure is limited only by one's own imagination and creativity.

what that means in practice is that it's actually possible to apply a strategy of 'graduated response' if you find a vendor is being too stubborn. it's not necessary to jump directly from responsible disclosure to full disclosure, you can gradually apply increasing amounts of pressure while at the same time not arming malicious attackers with new digital weapons.

unfortunately the disclosure debate has become religious. this is a big problem because it prevents people from considering alternatives. it polarizes opposing sides (which is odd when you consider that the true opposite of full disclosure is not responsible disclosure but actually non-disclosure) and creates an environment where people exhibit what emerson might well describe as 'a foolish consistency'. people need to get over themselves and their dogmas. disclosure (like many other things) is just a tool, and it's important to use the right tool for the job. sometimes the right tool may well be full disclosure, other times it may well be responsible disclosure, and still other times it might be something in between. the google folks are right to put the focus on protecting the users, but focus alone won't really help if they can't figure out how to use the right tool for the job (and one of them, at least, appears unable to).

china, disclosure, and malware

not too long ago, amrit williams wrote on his experience traveling in south-east asia and specifically his observation of their attitudes towards malware disclosure:

What I was shown was the most active and open distribution of malware, kits, and exploits I have ever witnessed. I will refrain from the details but considering the perceived insular nature of China and the openness of the US, I can tell you from the sharing of knowledge perspective we are way behind.

I asked some questions about disclosure and was met with puzzled looks and shaking heads.

though it's not completely unambiguous, i get the distinct impression (especially from wording of the statement that we're way behind) that he thinks we should be more like them... but i have to wonder what all that openness with regards to malware disclosure has actually done for china... are they better off than we are? are they better equipped to keep the malware problem in check?

i suppose perhaps if you were only looking at the technological side of the malware problem the easy availability of malware for study should theoretically be of help... but i have to wonder: when most of the population is not involved in the creation of tools to help defend against malware, and when those that are involved have fairly open access to malware even over here in the west, what advantage is china's undifferentiated openness really giving them in practice?...

if we don't just look at the technological side, however, if we include the social component as well (especially as it relates to malware creation) then that openness comes under a different light... what do we know about china and malware in broad terms? well, although finjan's figures suggest china is not the biggest host of malware, according to kaspersky they are the largest producer of malware...

sharing malware materials helps learning about malware, there's no doubt about that, but uncontrolled/undifferentiated sharing (as opposed to the more reserved 'only if i know and trust you' type of sharing) helps the creation of malware more than it does the defense against malware, and china may well be serving as an unrecognized object lesson in that fact... so the next time we look at how other cultures handle issues differently, before concluding that they're doing things better because they're adhering more closely to abstract principles that we value, lets make sure we look at the larger picture and not lose the forest amongst the trees...

i'm going to exploit DNS

which is to say i'm going to exploit everyone's interest in the DNS vulnerability dan kaminsky discovered in order to draw eyeballs... in other words: made you look!...

actually, i read on the recurity labs blog that every computer security blog on the planet had written something about the DNS vulnerability, and since i hadn't done so yet i was technically making a liar out of that blogger and that's no good...

problem is, though, that for the most part i really have nothing to say about the DNS vulnerability... i don't like writing about things i don't know and DNS is one of the many times many things i don't know all that much about...

the disclosure argument that ensued was somewhat familiar territory but it wasn't until i read andre gironda's comments to rich mogull's post about whose interests are being served that things finally crystallized in my mind about this... in a nutshell, the information is such that the vast majority of people have no legitimate need or use for it and so to keep it out of the hands of the black hats it really shouldn't be broadcast for the world to see, but at the same time there are enough people that may have a legitimate need or desire to know the information that any centrally coordinated effort to inform them will fail to include many and will only result in an exercise in elitism...

believe it or not, there's actually an old lesson from the AV field to be learned here because the AV community has had to deal with a very similar situation somewhere on the order of about a million times now... long, long ago they came up with a solution that actually works pretty well: a kind of darknet where links are formed between individuals who know and trust each others motives, competence, and judgment - basically a web of trust for sharing malware samples... the benefits are that the adherents to this approach avoid contributing to the sharing of information/materials with people who have no business handling them while at the same time giving everyone who may have a legitimate need or desire for the information/materials has a fair opportunity (but not a guarantee) to acquire them by virtue of being connected to someone else (or better still, many others) who has the means and desire to acquire it themselves...

it's not a perfect system, of course... there have been some instances where the wrong person was trusted, prompting people to rethink how they decide who to trust... there has also been no shortage of lazy bums who can't be bothered to put in the work necessary to actually earn the trust of at least one of their peers and instead whine about how unfair and elitist it is, like some petulant child who feels entitled to receive whatever s/he asks for... there's nothing stopping them from building the relationships necessary to participate in such a network but some people just don't understand that nothing worthwhile in this world is free...

i really think that the wider security community would benefit from adopting a similar approach to 'disclosure', and certainly in the case of the DNS vulnerability there could have been benefits if such a distributed trust-based network had already been established and was utilized... i say "already been established" because it can take time for a trust-based network to get connected and mature; but really, from a tactical point of view, information/intelligence gathering/sharing in hostile territory (and when we talk about broadcasting things on the global stage, the presence of hostile agents is beyond doubt) requires the use of covert channels such as this...

full disclosure

considering the tone of some of my past articles, some people could get the impression that i'm against full disclosure... nothing could be further from the truth...

i am in fact a proponent of full disclosure, but i don't approach the issue on simple blind faith as most people do... i've examined the arguments for and against full disclosure, i've looked at the underlying assumptions of those arguments, and i've made up my own mind about when full disclosure is appropriate and when it is not...

which is to say i support selective full disclosure... the fact is that those arguments against full disclosure have one thing right - making information on how to exploit vulnerabilities available to the public puts tools into the hands of bad guys... the reason full disclosure works is not because that doesn't happen, but because (theoretically at least) putting that information out there also hastens the correction of whatever mistake(s) lead to the vulnerability and therefore closes the window of exposure for the vulnerability... it's a security trade-off, and being able to close the hole once and for all tips the balance in favour of this practice because it winds up doing more good than harm...

if the vulnerability is not correctable, however, and some genuinely aren't, then the good that full disclosure is supposed to do can't be done...

take for example the following vulnerability... if an attacker knows your name, address, and credit card number, your credit card is vulnerable to unauthorized purchasing by the attacker... this is obvious, and i hope it's also obvious that the credit card purchasing system can't really be corrected to prevent this - this is one of those cases where full disclosure of the information needed to perform the attack (your credit card info) cannot result in this the attacked system being fixed to prevent that type of attack... the harm part of the equation is still present, of course...

many people don't consider the possibilitty that some vulnerabilities can't be fixed, however... they follow full disclosure blindly, with unwavering faith that it's going to improve the situation... they don't do that in my credit card example above, of course, because in reality everyone follows selective full disclosure without even realizing it... it seems to just be computer related vulnerabilities that people assume can always be corrected, which shows a regretable but understandable ignorance of the finer points of computer science... serious computer security researchers should know better though...

full disclosure is a good thing, when applied appropriately - but just as free speech has limits on when and where it's appropriate (ex. don't yell fire in a crowded theatre), full disclosure has limits too... that's why i'm selective in my practice and support of full disclosure...

malware and disclosure

some time ago i made the argument that it was wrong and irresponsible to publicly disclose viral materials or to share them in any lesser capacity with those you don't know and trust... the argument was essentially that making those materials more widely available increases everyone's risk of being exposed to viral materials while failing to hasten the closure of the window of exposure because the window of exposure for something inherent to the general purpose computing platform cannot be closed... basically, since the problem cannot be fixed, telling people how to exploit it and giving them the tools to do so has very significant dangers and no real benefits....

the question then arises - do my arguments against virus disclosure apply to other forms of malware?

while we don't (as far as i know) have the benefit of mathematical proofs that other forms of malware are just as inherent to general purpose computers, there is strong reason to believe they are and that the arguments against virus disclosure are just as applicable to other forms of malware...

take, for example, trojan horse programs... fundamentally they just do undesirable things that violate user expectations... since it is not possible for a computer to be able to examine any arbitrary program and determine all it's functions (thanks to the halting problem) it is therefore not possible for a computer to guarantee that any arbitrary program functions in a way the user would expect or that the user is adequately informed of the program's actual function... further, since all undesirable actions are only undesirable in certain contexts, and desire is beyond the computer's ability to accurately measure (we ourselves often don't know that something is undesirable until after we're exposed to it), so a computer cannot prevent programs from taking undesirable actions... therefore the ability to support trojan horse programs is inherent to general purpose computers and are not 'fixable'... therefore the window of exposure for trojans, in general, cannot be closed...

now the observant reader might have noticed that i classify most malware under the trojan category, so this result is fairly broad in it's scope, but maybe individual subcategories of trojans can be 'fixed'...

let's see - any system that accepts input (which is basically any computer worth considering and certainly all general purpose computers) can support rogue programs accepting that input... throw in the ability to store data and you have instant support for some kinds of spyware... throw in the ability to communicate with other computers over any kind of network and you cover all the rest of spyware as well as all remote control software like RATs and botnets... if the computer can produce some kind of human usable output then you have inherent support for adware...

the recent results from microsoft concerning virtual machine 'rootkits' are particularly damning... if the machine's hardware layer is capable of running virtualization software (and i see no reason why any general purpose computer wouldn't be capable of this) then any protection mechanism built into an operating system can be subverted, any function (high or low level) that the operating system can perform can also be used for ill gain, and the operating system itself can be forced to lie about all of it to the user...

and none of these things represent mistakes... they are all parts of fundamental limitations and intractable problems, things that cannot be overcome under our current models of computation... the conventional wisdom is that creating and publishing these types of malware helps to fix the problems that allow these types of malware to exist but it is done without trying to identify what that underlying problem is or trying to figure out whether that underlying problem is one that can be solved... many people in the computer industry are apparently ignorant of the fact that some problems are theoretically unsolvable, and while many instances of malware do indeed utilize genuinely fixable and avoidable mistakes those mistakes can be publicly disclosed by themselves without making malware out of them...

so, since the problems that allow malware to exist cannot be fixed, and the problems that can be fixed can be publicized without making malware out of them, the sharing of malware materials with those you don't know you can trust cannot possibly help to advance the security goals of the population and quite obviously (by putting attack tools where criminals can get them) increases the risk of exposure for everyone and is therefore wrong-headed/unethical/irresponsible...

not all vulnerabilities were created equal - people shouldn't be surprised that some aren't as susceptible as others to the security process known as full disclosure...

viruses and disclosure

let me make this perfectly clear - i do not support the indiscriminate sharing of viral materials...

you should not share viruses, source code, etc. with people you don't know you can trust (both competence and ethics-wise) and you should not ask for such materials from people you have no reason to expect trust from...

the argument for not sharing materials with people you don't know you can trust should be obvious... they might do something bad or stupid with the materials you give them... the argument against asking is that it legitimizes the sharing of materials in situations where it deserves no legitimacy...

there are some misguided notions that the full disclosure policy that works so well for vulnerabilities would be equally well applied to viruses... lets examine that more closely...

a vulnerability, ultimately, is a mistake... whether it's a mistake in the design or in the implementation doesn't matter, it's a mistake that in an ideal world could have been avoided and in the real world can (hopefully) be fixed... full disclosure of vulnerabilities benefits us in a variety of ways...

1. first and foremost it places pressure on the people/organization responsible to fix the problem in a more timely manner than they may have otherwise been inclined to do.
2. it helps us learn more about the mistake so that in the future we might better avoid it or similar mistakes.
3. it helps us identify when a program or system no longer meets our expectations of trustworthiness if/when an unacceptable number of vulnerabilities are uncovered or not enough is done to rectify them.

viruses, on the other hand, are not mistakes nor do they depend on mistakes (though some particular viruses may depend on particular vulnerabilities)... the ability to support viral infection is inherent to ALL general purpose computing platforms... it cannot be fixed or avoided - and since it cannot be fixed or avoided, it cannot be used as a discriminating factor when judging the quality of the platform or organization (the fact that windows has more viruses than linux has more to do with the number of windows users there are and the nature of those users than with the fact that windows is garbage)... none of the benefits we receive from full disclosure of vulnerabilities are achievable in the virus realm... what is achievable is

1. a state where it is easier for people learning to write and spread viruses to get their hands on examples.
2. a state where it is easier for people who wish to use existing viruses as weapons of vengeance to get their hands on viruses.
3. a state where it is easier for novices to get their hands on samples even though they don't have sufficient competence with viruses to deal with them safely.

as such, sharing viruses with people you don't know you can trust cannot be considered to be responsible handling of viral materials and is to be discouraged... instead, one should only share such materials with people one knows one can trust (who in turn do the same - leading to a 'web of trust') and only request such materials from those who you can reasonably expect will trust you...