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.

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).

why the disclosure debate does in fact matter

some time ago dennis fisher published a post on threatpost explaining why the disclosure debate doesn't matter.
from the article:

In recent discussions I've had with both attackers and the folks on enterprise security staffs who are charged with stopping them, the common theme that emerged was this: Even if every vulnerability was "responsibly" disclosed from here on out, attackers would still be owning enterprises and consumers at will. A determined attacker (whatever that term means to you) doesn't need an 0-day and a two-week window of exposure before a patch is ready to get into a target network. All he needs is one weak spot. A six-year-old flaw in Internet Explorer or a careless employee using an open Wi-Fi hotspot is just as good as a brand-spanking-new hole in an Oracle database.

his argument seems to be that since a determined adversary is going to get in regardless of whether people practice full disclosure or responsible disclosure, the method of disclosure makes no difference. if they don't use the vulnerability in question then they'll just use something else.

what this basically boils down to in practice (whether dennis likes it or not) is 'since they're going to get in anyways we might as well make it easy for them'. does that seem right to you? it doesn't to me. how about this - if it doesn't matter whether we keep a particular vulnerability out of the attacker's toolbox (since they'll just find some other way to get in), why does it matter if we fix the vulnerability at all? whether the vulnerability is kept hidden or made non-existent, it should have the same effect, namely that it doesn't get exploited, so if one of those is pointless doesn't that mean the other one is too?

this strikes me as the security equivalent of nihilism, which quite frankly is not conducive to progress. as such i have an exercise for all those agree with dennis' sentiments (that the disclosure debate doesn't matter) to rouse them from their apathy:

publicly post your full personal details, including name, address, phone number, bank account number, credit card number, social security number, etc, etc.

after all, if someone really wants to steal your identity they're going to do it anyways, so you might as well  hand the bad guys the tools they need on a silver platter, assume you're going to get pwned (in accordance with the defeatist mindset that has become so popular in security these days), and start the recovery process. just bend over and think warm thoughts.

"that's not the same thing" you say? well of course not. in one instance you're handing over tools that enable attackers to victimize somebody somewhere (often many somebodies all over the place) and in the other you're handing over tools that enable attackers to victimize YOU. clearly things are a lot different when it's your own neck on the line than when it's some nameless faceless mass of people who are out of sight and out of mind.

will responsible disclosure prevent attackers from victimizing people or organizations? in the most general sense, no. but there is definitely value in making things harder for them, and it should be blatantly obvious that there is no value in making things easier for them. the concept of not making the attacker's job easier is why there's a disclosure debate in the first place, and the fact that so many people still don't understand that is why it's still important.

full disclosure as disarmament

i suppose it was only a matter of time before i linked to some article that touched on the sad story of tavis ormandy (backstory for those living under a rock: he disclosed a serious windows flaw to the public after a rather pitiful amount of negotiation with microsoft over the patch timeline). i'm a little too late to the party to bother with vilifying him, but the arguments used to support him could stand and be reused in the future and those need to be addressed.

the most interesting of those arguments that i've witnessed so far comes from lurene grenier who wrote a guest article for zdnet about how tavis supposedly acted responsibly by fully disclosing the details of the vulnerability. what interests me so much about her argument is the idea that tavis was actually disarming the bad guys:

So we must ask, were the actions that  Tavis took responsible? Would it have been more responsible to allow a company to sit on a serious bug for an extended period of time? The bugs we are discussing are APT quality bugs. Disclosing them removes ammunition from APT attackers.

now i shouldn't have to remind people that full disclosure actually puts ammunition INTO the hands of bad guys - and this case was no exception. it was only a matter of days before people started seeing attacks leveraging tavis' discovery in the wild. that doesn't contradict lurene's argument, though, because her argument is carefully constructed around the concept of APT (advanced persistent threat) attackers. she contends that when vulnerabilities of this calibre are disclosed they are no longer of use to "serious attackers".

i propose a different way of looking at things:

1. when an attack's days become numbered, an attacker who had been sitting on it with plans on using it might just let it fade away OR such an attacker could decide to pull the trigger right then and there to get as much use out of it as possible in the time s/he has left. patches and mitigations take time to develop and deploy so any disarmament sort of effect would not be immediate.
2. it seems entirely probable to me that a so-called serious attacker, specifically one who qualifies as an advanced persistent threat, would not just sit on the attack and wait. such an attacker would have used the attack to gain access to whatever high-value target they had in mind long ago. it is easier to retain access (which can be done through more mundane methods) than to gain it in the first place. so while it may well be possible to liken the disclosure of a high value vulnerability to the removal of ammunition, it seems likely that that ammunition has already been spent, and removing spent ammunition doesn't have quite as big a benefit for us as lurene probably had in mind.
3. the implication that only APT style attackers are serious, that they're the only ones we really need to worry about is quite frankly farcical. while it's true that they are one of the few credible threats to power generation facilities and other infrastructure level targets, to imply that they are the only ones we need to worry about displays the same narrow-mindedness that we've previously seen applied to financially motivated cybercrime. there are more things in heaven and earth than are dreampt of in your philosophy if all you care about is APT.
4. finally, even if we were to accept the argument that full disclosure takes ammunition away from APT-style attackers, it demonstrably puts it in the hands of other attackers. taking ammunition out of the hands of a highly selective minority and putting it into the hands of a far larger, less discriminating and less controlled adversary doesn't seem like all that clear-cut a case of making things better. it may lessen the potential impact of the attack in theory (arguably), but it demonstrably increases the probability and scope of the attack in practice. 

if i were to take arms away from terrorists and give them to criminals, would that really be better? that's a really tough argument to make - i don't think it's supportable. the concept of disarming APT-style attackers is an interesting one, but responsible disclosure does the same thing and it minimizes the unwanted fall-out. so when faced with a choice between 2 evils did tavis ormandy choose the lesser evil? not so much, and that makes his actions irresponsible.

offensive full disclosure

in my previous post about full disclosure i came up with some pretty restrictive guidelines for when full disclosure was ok. that was specific to disclosure of vulnerabilities in legitimate software/services. some time ago richard bejtlich published a post about about performing full disclosure for vulnerabilities found in attack tools - in other words the sort of software used by the bad guys to victimize innocent users.

while there is admittedly some gray area where legitimate software and attack tools might conceivably overlap, the tools richard described aren't anywhere near being legitimate - they are geared to exploit vulnerable systems and there's virtually no legitimate reason for doing that.

obviously that changes the ethical landscape a lot with respect to full disclosure. the users of such software are not innocent by definition, so actions that put them in harm's way aren't nearly so poorly regarded as those that put innocent users in harm's way. in fact, when cybercriminals are subjected to the same sorts of digital attacks as those they might otherwise perpetrate on others, some might even consider it poetic justice.

richard doubts the tactical efficacy of full disclosure against attack tools for 2 basic reasons:

1. it will alert the attack tool developers to the problem and ultimately result in the vulnerability being fixed
2. white hats have to follow rules that prevent them from forming waves of attacks against black hats the way black hats would do if a vulnerability in IE were disclosed

while reason #1 is certainly true, there's still a window of opportunity between the disclosure and the fix during which attackers could be successful. furthermore, there is an undefined window of opportunity between release of the fix and deployment of the fix when attacks could also be successful. remember that security fixes aren't necessarily applied as soon as they're available, and in the case of attack tools specifically there are a number of users of those tools who are not using the most recent versions because they don't want to pay for the product or for support. those using pirated versions of the attack tools are unlikely to get a fix and may not even be aware of a need for one - if they can't be bothered to pay for black hat software it's possible they don't care to invest in developing their own expertise in this field either (otherwise they could just build their own attack tools) and so probably wouldn't be paying attention to security advisories for the attack tools.

reason #2 is also true, but it assumes that the only people interested in attacking the black hats are the white hats and that simply isn't true. taking into account the low risks of getting caught that cybercriminals face, if i were a cybercriminal then the idea of letting some other poor shmuck run a criminal campaign and then simply breaking in and stealing their loot actually seems pretty appealing to me. there's less work involved, less visibility (and so even less risk than the poor shmuck who did things the hard way), etc. stealing from other thieves after they've already done all the hard work of collecting and aggregating whatever it is they were after just seems like the smarter way to go.

furthermore, from a white hat perspective having the black hats attacking each other is also appealing. the more they focus on each other the less they focus on the rest of us. of course, the point richard made about white hats no longer being able to use the vulnerability for their own operations against the attackers would still be true but only if full disclosure were followed in the case of all vulnerabilities. since that isn't the case for vulnerabilities in legitimate software, since only some of the vulnerabilities people know about get disclosed, i see no reason to worry about that happening in the case of offensive full disclosure. some vulnerabilities will no doubt be held back for precisely those sorts of operations.

frankly, i really like the idea of offensive full disclosure - it seems like a win-win proposition to me.

some thoughts on full disclosure

long time readers may recall that i'm not actually an opponent of full disclosure. i suppose this may come as a shock to some newer readers but it's true, i actually support full disclosure - but only in some very specific circumstances which i intend to refine here.

in contemplating my post about responsibility the concept of full disclosure came to mind. specifically the question of how it works. how does full disclosure convince vendors to act? why is it persuasive? where does full disclosure get it's teeth from? these are important questions because, as it turns out, the answers affect how we consider full disclosure in the context of responsible behaviour.

the concept of full disclosure is often framed so as to make it appear to be a vendor vs researcher issue where the researcher is the champion of some abstract notion of security and the vendor is being recalcitrant, perhaps even practicing outright denial that a problem exists. unfortunately this sort of framing ignores two very important players - the malicious attackers and the vendor's customers. of course the argument can be made that those two groups are taken care of when the vendor submits to the researcher's authority and fixes the vulnerability the researcher disclosed; and maybe that's true, but it glosses over a lot of the inner workings of the process.

now given the most reasonable characterization of a vendor is that their primary interest is the bottom line, it stands to reason that full disclosure persuades them to act by threatening their bottom line. the bottom line, of course, comes from their customers. but most customers don't read security forums or mailing lists. they aren't aware of any security problems, and the certainly aren't changing their behaviours or buying patterns based on things they aren't even aware of. malicious attackers, on the other hand, do read a variety of sources for information about new vulnerabilities, and they use that information to launch attacks which affect the vendor's customers. when a group of people are being victimized and the commonality between them is discovered to be the vendor's product/service, that harms the vendor's brand and that leads to fewer customers which ultimately affects the vendor's bottom line.

so let's look at full disclosure this way: it operates by giving attackers the information they need to launch attacks. the attackers then launch those attacks and victimize the customers. attackers have often proven able to produce attacks using a vulnerability faster than the vendor can create a fix for it (often a matter of days compared to weeks or months from the vendor's side). as a result the vendor rushes out a fix in order to protect as many of their customers (as much of their cash cow) as possible. at this point all is supposedly right with the world, unless you take into consideration the people who patch late or the fact that rushing things out the door generally results in poor workmanship and has the potential to cause more problems than it solves.

it needs to be said that this process, this chain of events breaks down if the attackers don't attack. they have to attack at least most of the time in order for threat to the vendor's bottom line to be credible. if full disclosure didn't result in attacks a significant amount of the time then there would be no reason for vendors to believe the disclosure would affect their bottom line and full disclosure would cease to be effective at persuading vendors to bow to the whims of researchers. consequently, whether researchers are aware of it or not or whether they're willing to admit it or not, hoping for full disclosure to affect change means hoping that attackers mount successful attacks as a result of full disclosure. they might hope that their particular disclosure is an exception to this rule, but that's more than a little unrealistic.

so if full disclosure only works by leveraging the bad guys, if it's a process that manipulates attackers into behaving in a way that forces the vendor's hand and throws innocent users under a bus along the way, then why on earth would i not be entirely against it? because under certain circumstances it's better than the alternatives. what circumstances would those be? when the attackers demonstrably already have the info without the benefit of the researcher's disclosure (better still if it's mainstream because then it's unlikely the disclosure will even raise the vulnerability's profile amongst attackers) and the vendor actually is in a state of denial. if the researcher's contribution to harming users will be demonstrably negligible and the vendor is stubborn beyond reason and really needs a swift kick in the ass then the ethical arguments against full disclosure break down.

understanding KHOBE

there's been quite a lot of press given to the research surrounding KHOBE this week, and while the coverage on the normal anti-malware blogs i follow was quite good, coverage outside that community left something to be desired (accuracy? comprehension?).

to start with, KHOBE is not so much an attack as it is a technology. KHOBE stands for Kernel HOok Bypassing Engine. it's technology developed by matousec to do exactly what that name suggests - bypass kernel hooks. it does this with a technique that matousec calls argument switching but which has in the past been called a time-of-check-to-time-of-use attack (or TOCTTOU attack; see this post on the eset threatblog).

this sort of attack is an active countermeasure, meaning a piece of malware implementing this attack has to be active in memory in order for attack to be performed. this means, first and foremost, that in order to mount this sort of attack the malware already has to be able to get past traditional scanning technologies without using argument-switching, since they examine the program before it's allowed to execute and become active.

as such, the anti-malware techniques that argument-switching is a countermeasure for are behavioural techniques (including, but not limited to certain self-defense techniques that anti-malware products use to prevent being shut down by malware that becomes active). by switching the contents of memory after a chunk of code has been checked for potentially malicious intent but before it's passed to the system to execute, this attack manages to prevent behavioural detection/prevention techniques from seeing the code that is actually going to be executed and in that way constitutes a kind of stealth that works against behavioural techniques (though it only works against behavioural techniques that are implemented in a particular way - using the particular kernel hooks that KHOBE was designed to bypass).

behavioural stealth is interesting at least so far as it demonstrates some of the limits of behavioural techniques to protect systems from attack (all techniques have limitations). from a strategic point of view, once a piece of malware is able to execute it's already passed every opportunity you had to prevent compromise outright - at that stage the only thing left is to contain the damage using behavioural techniques and/or sandboxing. behavioural stealth could clearly render containment by behavioural blocks ineffective (again, if it's implemented using the kernel hooks in question) and might even bypass the sandboxing technology, depending on how it's implemented.

although the attack has apparently been known about for some time (much longer, it seems, than the folks at matousec realized), it hasn't yet been used. however, that may now change as the current threat ecosystem is much different from when TOCTTOU was originally discussed. matousec has raised the attack back out of the depths of obscurity and there are now any number of computer criminals out there who would be more than willing to take matousec's research and use it for their own gains (much like what happened to eEye's bootroot research). this is the risk one takes when publishing attack research for the world to see, so you have to weigh your options very carefully to see if it's really worth arming the bad guys. and of course don't just follow full disclosure dogmatically simply because it seems like that's what everybody else does - as emerson said "a foolish consistency is the hobgoblin of little minds".

month of 'do as i say'

well today is the first day of july and that means it's also the first day of the month of twitter bugs. like past 'month of X bugs', each day a security vulnerability relating to the subject product/service (in this case twitter) will be disclosed to the public.

why are they disclosing these vulnerabilities to the public? as with any exercise in full disclosure the idea is to force the company(ies) involved to clean up their act and fix the disclosed vulnerability. full disclosure puts the information into the public sphere so that many people are aware of it and something as attention-grabbing as a 'month of X bugs' captures even more mind-share and gets it that much closer to the mainstream.

in theory this is good for the public. in theory the researchers doing the disclosure are doing a good deed because they care about security and the company(ies) they're pantsing are lazy, arrogant boors who don't care about security or the public and who need to be forced into doing the right thing. and supposedly fixing the individual bugs the vulnerability researchers identify is the right thing to do.

but what if the theory is wrong? not all companies are created equal (nor are all vulnerability researchers for that matter). nobody knows what goes on inside a company except the people inside that company. it's possible that a given company may actually be working on a comprehensive upgrade to their security posture that would obviate swaths of bugs including the ones that get identified by outside researchers. but that would have to be delayed and the company's time wasted so that they can chase down these individual bugs one at a time in order to appear to be doing something. such is the consequence of shifting vulnerability notification to the public sphere.

now, i'm not going to be disingenuous and suggest this is what happens all the time or even most of the time, but being in software development i feel confident that it is happening some of the time.

external full disclosure practitioners have no way to know that, however, nor have i seen any indication that they care. despite the warm and fuzzy ideology behind the practice, full disclosure is an application of force. it is an exercise in coercion, an example of using public relations to bend a company to the vulnerability researcher's own will because supposedly the researcher knows better than the company what is best for the company's users.

i'm no more a fan of lazy, arrogant, boorish companies than the next guy, but belligerent 3rd parties leave a bad taste in my mouth too.

surprise! offensive computing is, well, offensive

from a website i can't link to for reasons detailed here:

Offensive Computing was formed by Valsmith and Danny Quist as a resource for the computer security community. The primary emphasis here is on malware collections and analysis for the purpose of improving people's abilities to defend their networks. There is a noticeable lack of public sources of malware and malware analysis available. Those that were available were either for sale or limited to a small number of users. We provide resources such as live copies of malicious software, md5sums to search on and analysis of the malware to the general public.

so, assuming they're legit (and that's quite the assumption to make where cult of the dead cow members are concerned - think "back orifice", the RAT [silent installs for remote control software is not a good thing to do, boys and girls] they created that basically put them on the map years ago) we have yet another group of people who think sharing malware publicly is good and have clearly not considered how realistic their expectations are about the supposed benefits OR the costs to society at large OR the lessons to be learned from other attempts to do roughly the same thing...

the supposed benefits
proponents of these kinds of projects usually trot out noble ideas like full disclosure, open source, and collaboration... if only things could work out the way they planned... full disclosure, as i've stated before, only has a positive cost/benefit trade-off when the underlying problem can be fixed (which generally isn't the case with malware)... openness is great in some contexts, but not when dealing with dangerous materials, that much should be patently obvious... finally, the vast majority of ordinary users will never directly participate in the collaboration or even know it exists and the established experts already have better (read: less naive/negligent) channels through which they can get the same materials...

normal people do not use malware to help them defend their networks from malware - they use security software to defend their networks, security software written by other people, generally a relatively small group of people (small in comparison to the number of people who use it)... this isn't going to change - it will never be the case that the magority of the population will involve itself in the technical minutiae of synthesizing solutions to specific malware problems... how does free public access to live malware actually help these people who are trying to defend their networks? what impact does having such access have on the quality or effectiveness of the software that they're actually using to defend their networks with when they aren't the ones making that software?

clearly having such access does not help these users and has no impact on the quality of the tools they use - all that really matters is that the people who make the tools have access, and those people have access even without a project like offensive computing (otherwise how'd they get by up to now?)... the people actually building the tools have samples and they have contacts with other people that have samples and that they share a mutual trust with - that is how it works in the anti-virus community and that is how it should work in the wider anti-malware industry (if it doesn't, ask your anti-malware provider why they don't co-operate with other anti-malware providers - if they give you bullshit about competition on an issue of public safety like this, well it's just that, bullshit - there are plenty of other ways to compete that don't compromise or otherwise handicap the process of providing the public at large with the tools necessary to keep them safe - vote with your wallet)...

i suppose the argument could be made that public access helps those just breaking into the anti-malware market, but in reality there's all kinds malware already readily available to such people so they can build their malware databases organically... at the same time they can build their reputations and trust relationships with others in the anti-malware community so that by the time they need access to malware they can't easily find themselves they'll have people they can turn to...

that just leaves the people who can't or won't build those trust relationships as being the real beneficiaries of a project like this...

the cost to society
it's important, whenever examining some proposal to improve security (as offensive computing does), to not blindly look only at the promise such a proposal has - you also have to look at how the system can be gamed... in this case it's fairly simple - it can be used to put malware in the hands of bad guys of course (and it's clear why that's bad) but it also can put malware in the hands of lazy/careless people, incompetents, looky-loos, and all manner of other folks who have no business handling malware - the second type of new age virus writer as described in sarah gordon's paper generic virus writer 2, the one you may have working in your IT department right now, is exactly this sort of person...

does putting malware into the hands of these people benefit security? are we (or our computers, data, or privacy) safer by giving malware to the people most likely to do something stupid or malicious with it? of course not...

and these are exactly the same sort of people most likely to seek out and use such a project - they're interested in the samples, this is a cheap and easy way to get them, and they don't have to sacrifice anything they actually value (like principles about responsible malware handling)...

all this boils down to more variants being made, more malware being 'deployed', and a facilitation of the collaboration going on between malware creators by doing away with the innovation bottleneck of conventional participatory collaboration and replacing it with a new and less constrained model...

lessons that could have been learned
i suppose i could mention that the pro-malware community in general and the vx in particular have a long history of making their 'wares freely (as in speech, and often as in beer) available to the public with everything from bbses to cd compilations to usnet newsgroups to irc chatrooms to web pages... they do it not because it helps the good guys (in fact the good guys often help to get malware trading sites shut down) but because it helps other bad guys like themselves... however, those projects aren't intended to help the good guys so it's really not comparable...

i suppose i could also mention the sites for sharing exploit code... superficially they seem like they'd be comparable to this offensive computing project, however, as i've said before, exploit disclosure and malware disclosure are 2 very different things - the cost/benefit analysis of disclosing software defects and how they can be exploited comes up positive for us while the cost/benefit analysis of disclosing malware does not, so this too is really not comparable...

"so then what project is comparable?" you might ask - well how about rootkitDOTcom? they make a form of malware freely available on that site with the stated goal of helping security researchers tackle the 'rootkit' (*cough* stealthkit *cough*) problem... so let's look at how well that's worked out so far - over the past couple of years the stealthkit problem has gotten worse, not better... they're more widely used, they're more widely sought after, and they're getting more and more sophisticated... on that basis alone it would seem like rootkitDOTcom is failing to acheive it's supposed goals...

but the rootkitDOTcom example goes beyond simple failure to do good, the most damning thing is how much BAD it's done... i've described in the past how one of the site's founders made a stealthkit available on the site and how that stealthkit (unaltered from the compiled binary available on the site) then went on to become one of the most widely deployed stealthkits in the world... it's not like this was malware that was captured in the wild and whose success in the wild when it was freely available on a rather high profile site could be explained away as coincidence... it's also not like this malware was self-replicating so it's success can't be blamed on that either... it started on that site and the bad guys used that site, took that stealthkit and used it against countless computer users...

there is no question that the bad guys can do this or that they have done this in the past or that they will do it again in the future - it's a forgone conclusion and offensive computing is falling right into their hands... they go on to say that:

This site does NOT encourage or condone the spreading or propagation of viruses or worms. Thats exactly what this site is designed to help defend against.

The intent of providing live copies of malware is so that the community can collaborate on identifying and analyzing them in order to develop snort signatures and other defenses.

well, their intent may be good but the road to hell is paved with good intentions... they may not condone the spreading or propagation of viruses or worms but in practise i can guarantee you they'll wind up facilitating it... tens of thousands of live malware samples freely available is just too good a target... the av community knows full well (from experience) what can happen by sharing samples with just one wrong person - that's why they've developed the stringent policy they now follow... sharing malware with everyone will invariably lead to the bad guys misusing that malware and making the entire project part of the problem rather than part of the solution...

mcafee on the possibility of cell phone stealthkits

the mcafee avert blog has a post on it expressing concerns that the recent release of symbian ROM images and research may lead to the development of stealthkits (what mcafee and most of the rest of the industry are currently referring to as rootkits) for cell phones...

after their stealthkit report of a couple of months ago it would be easy to interpret their newly expressed concern as meaning they feel that the ROMs and research should not have been released...

i don't know if that was actually the intention of the mcafee blogger in question, but just in case: you cannot use the threat that security research could be used for nefarious purposes as a means to justify stifling the public dissemination of any arbitrary type of security research...

while it is a risk in all public disclosure of security research, only some types of research documents (generally actual malware) fail to give the security benefits when shared publicly that justify public disclosure... i may have agreed with the sentiment from mcafee that stealthkit disclosure shouldn't be afforded the same respect that normal full disclosure enjoys, but i think this case (that doesn't disclose actual malware but just research that malware creators might be able to use) legitimately falls under full disclosure... there are plenty of security benefits that can be had by examining the symbian OS...

vulnerability escrow

while engaged in a discussion about a vulnerability disclosure over at spire security an idea came to me...

one of the reasons people disclose vulnerabilities without making any effort to first work with the affected vendor(s) to correct the problem is that they want to be known as the person who discovered the vulnerability - they want to be able to prove they were the first to discovered it and the way to do that is to blurt it out in a public forum so that it becomes trivial to verify who was first to post the vulnerability...

ignoring the fact that putting the advancement of your reputation ahead the security of others is an entirely self-serving thing to do, i think there's a relatively easy solution to this... put the details of the vulnerability into escrow with a trusted 3rd party such that the 3rd party timestamps the details you give them and keeps them secret until the researcher who submitted the vulnerability unlocks it for public scrutiny... that way the researcher can prove when s/he discovered the vulnerability and get the credit s/he's due and still work with the vendor to correct the problem...

ideally we'd want to fix the vulnerability prior to public disclosure so that the window of exposure is more or less closed when information that might have otherwise lead to exploitation in the wild is released... of course things don't always go as we'd hope and sometimes vendors dick researchers around instead of taking them seriously so full public disclosure before the vulnerability gets corrected may still be necessary some of the time, but hopefully only as a last resort...

of course this idea of having a vulnerability escrow system only addresses the problem of letting people motivated by personal advancement follow responsible disclosure and still get the credit they were seeking... it doesn't address other motivations like spite, where they try to punish the vendor by releasing vulnerability information - that hurts the vendor by hurting their customers and that kind of collateral damage clearly doesn't work towards the greater good...

now that i've written this, it occurs to me that vulnerability escrow can't be a new idea... and google says i'm right, it's not... so then this is my voice supporting the idea...

mcafee's rootkit report: an alternative interpretation

the internet has been relatively a-buzz this week over a report (well, part of a report, actually - don't ask me why they couldn't release the whole thing) out of mcafee on the growth of the 'rootkit' threat... a lot of attention has been paid to mcafee's rather poor choice of words when the key findings blamed the "open source environment" for the increased proliferation and complexity of rootkits...

first, yes it really has nothing to do with "open source"... the concept that the author was probably struggling for when he settled on "open source" was public or full disclosure... a software licensing paradigm has nothing to do with 'rootkits' getting more complex or being deployed more frequently, but public disclosure is an enabling practice... coming out against full disclosure or anything like it isn't a popular thing to do in security circles these days, though, which may be why the author tried to find some other term...

also, mcafee named and shamed rootkitDOTcom as a possible leading cause of the worsening 'rootkit' problem... a lot of people took issue with this, mostly they're the folks who feel rootkitDOTcom is doing nothing more than practicing full disclosure and that full disclosure can do no wrong... some even try to quote bruce schneier with the old "security by obscurity is no security at all" line and to those people i'll direct you to what bruce schneier has actually written about full disclosure, particularly about irresponsible (and perhaps even criminal) disclosure...

now mcafee has it partially right, the public disclosure taking place on rootkitDOTcom and various collaboration sites and blogs IS at least partially responsible for the increase in complexity of 'rootkits'... by sharing malware source code and even compiled binaries with literally everyone (as rootkitDOTcom does) the supposed good guys are adding their voices, their knowledge, and their skills to the collaborative efforts of the bad guys...

that said, mcafee's figures show something in the growth patterns that availability of information cannot explain... collaboration sites in general and rootkitDOTcom in particular have been around for years so why then does the growth rate change so dramatically when it gets to 2005? availability of source and binaries are enabling factors, not causative ones - they don't drive the innovation or deployment of this type of malware...

something changed, something happened in 2005 that made 'rootkits' a whole lot more popular - i'll give you 3 guesses as to what that was and the first 2 don't count... that's right, sony bmg / first4internet / xcp... the media circus surrounding that debacle kept 'rootkits' in the public eye for a long time... it made them mainstream, not only in the eyes of the general internet public but in the malware creators' eyes as well... the attackers interest was piqued, their imagination was sparked, the tools they needed were easy to find and so now we are witnessing something not that unlike the slashdot effect except in malware development... throngs of people who weren't making 'rootkits' before, who probably weren't even aware of the kind of stealth technology that was available or how it could be used to their advantage, now are and that's what mcafee's numbers represent...

does that mean the media is to blame for building all this interest in 'rootkits'? maybe - i'd certainly like to blame some of the ills of the world on their sensationalism... the bad guys are still the ones responsible for doing bad things, but the media pointed a whole bunch of them in a new direction... that doesn't mean that greg hoglund and co. of rootkitDOTcom are off the hook, though... for all protestations of helping people learn about threats, learning for the sake of learning doesn't improve security - they aren't helping to close the window of exposure for this class of threat but they are helping to arm the bad guys... that's called being part of the problem rather than part of the solution...

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...