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.

the anti-virus harm balance

anti-virus software, like all software, has defects. sometimes those defects are functional and manifest in a failure to do something the software was supposed to do. some other times the defects manifest in the software doing something it was never supposed to do, which can have security implications so we classify them as software vulnerabilities. over the years the software vulnerabilities in anti-virus software has been gaining an increasing amount of attention by the security community and industry - so much so that these days there are people in those groups expressing the opinion that, due to the presence of those vulnerabilities, anti-virus software does more harm than good.

the reasoning behind that opinion goes something like this: if anti-virus software has vulnerabilities then it can be attacked, so having anti-virus software installed increases the attack surface of the system and makes it more vulnerable. worse still, anti-virus software is everywhere, in part because of well funded marketing campaigns but also because in some situations it's mandated by law. add to that the old but still very popular opinion that anti-virus software isn't effective anymore and it starts looking like a perfect storm of badness waiting to rain on everyone's parade.

there's a certain delicious irony in the idea that software intended to close avenues of attack actually opens them instead, but as appealing as that irony is, is it really true? certainly each vulnerability does open an avenue of attack, but is it really doing that instead of closing them or is it as well as closing them?

if an anti-virus program stops a particular piece of malware, it's hard to argue that it hasn't closed the avenue of attack that piece of malware represented. it's also hard to argue that anti-virus software doesn't stop any malware - i don't think anyone in the anti-AV camp would try to argue that because it's so demonstrably false (anyone with a malware collection can demonstrate anti-virus software stopping at least one piece of malware). indeed, the people who criticize anti-virus software usually complain not about set of malware stopped by AV being too small but rather that the set of malware stopped by AV doesn't include the malware that matters most (the new stuff).

so, since anti-virus does in fact close avenues of attack, that irony about opening avenues of attack instead of closing them isn't strictly true. but what about the idea that anti-virus software does more harm than good? well, for that to be true anti-virus software would have to open more avenues of attack than it closes. i don't know how many vulnerabilities any given anti-virus product has so i can't give an exact figure of how many avenues of attack are opened. i doubt anyone else can do so either (though i imagine there are some who could give statistical estimates based on the size of the code base). the other side of the coin, however, is one we have much better figures for. the number pieces of malware that better known anti-virus programs stop (and therefore the number of avenues of attack closed) is in the millions if not tens of millions and that number increases by thousands each day. can the number of vulnerabilities in anti-virus software really compare with that?

it's said that windows has 50 million lines of code. if an anti-virus product were comparable (i suspect in reality it would have fewer lines of code) and if that anti-virus product only stops 5 million pieces of malware (i suspect the real number would be higher) then in order for that anti-virus product to do more harm than good it would need to have at least one vulnerability for every 10 lines of code. that would be ridiculously bad software considering such metrics are usually estimated per 1000 lines of code.

now one might argue (in fact i'm sure many will) that those millions of pieces of malware that anti-virus software stops don't really represent actual avenues of attack because for the most part they aren't actually being used anymore. they've been abandoned. counting them as closed avenues of attack isn't realistic. the counter-argument to that, however, is to examine why they were abandoned in the first place. the reason is obvious, they were abandoned because anti-virus software was updated to stop them. the only reason why malware writers continue making new malware instead of resting on their laurels and using existing malware in perpetuity is because once anti-virus software can detect that existing malware it generally stops being a viable avenue of attack. so rather than the abandonment of that malware counting against anti-virus software's record of closing avenues of attack it's actually closer to being AV's figurative body count.

there is still malware out there that anti-virus software hasn't yet stopped, and as that set is continually replenished it's unlikely that anti-virus software will stop all the malware. it has stopped an awful lot so far, however, so the next time someone says anti-virus software does more harm than good (due to it's vulnerabilities) ask them for their figures on the number of vulnerabilities in anti-virus products and see how it compares with the number of things anti-virus software stops. i have a feeling you'll find those people are full of it.

on exploit detection

data is code and code is data. i know that people like to think of data and code as being inherently different and separate from each other but in the end it's all just symbols in various languages on a real-world analog to the turing machine's infinite tape. fetching the next instruction, decoding it, and performing an operation based on what resulted from that decoding is not intrinsically different from fetching the next chunk of data, parsing it, and performing an operation based on what came out of that parsing. the ability to treat code as data is what allows us to distribute software, and the ability to treat data as code is what allows us to add new functionality to our general purpose computers that they weren't able to do before.

the distinction between programming languages and other input languages is simply that a programming language is intended to be used by programmers to create programs that are used by other people and other input languages are intended to be used by everybody else for (ostensibly) less complex purposes. it's really a matter of complexity, more than anything else, but it turns out that there are many input languages that aren't thought of as programming languages but are turing-complete and so are just as complex as any programming language. further, it's not just that there are two groups of languages (trivial and complex), but rather an entire spectrum.

with that in mind it's little wonder that data in the form of exploits can be just as bad as more traditional malware, but the implications go beyond just that. since data and code are not intrinsically different, since exploits are essentially malicious programs written in the input language for a vulnerable piece of software or hardware, some of the things we know to be true about malware should also hold for exploits.

specifically, the problem of deciding if an arbitrary input exploits a vulnerability seems like it should be reducible to the halting problem. i can certainly imagine trivial input languages where the presence or absence of an exploit is easily decidable, such as one where there are only 2 possible inputs, a legitimate one and one that triggers a vulnerability. however, in general, and certainly in no small part due to the existence of turing-complete languages, i'm fairly confident in saying that this problem is analogous to the virus detection problem. and THAT means that the problem of exploit detection, regardless of how it's approached in practice, is ultimately subject to the same limitations as the problem of virus detection.

to that end, testing exploit detection can run into the same methodological problems that testing virus detection can. for example, creating one's own exploits and testing against those instead of drawing exploit samples from the wild presents the same kind of problem that creating one's own viruses and testing against those would. namely that what is created in the lab does not necessarily correspond to what exists in the wild and so a product's ability to detect what was created in the lab doesn't necessarily correspond to it's ability to detect what's in the wild. certainly it's trivial to see how that would be true for products that detect known exploits using a method similar to known-malware scanning, but even for products that attempt to parse suspected exploits exactly the same as a vulnerable application would this would be the equivalent of emulating suspected viral code which we already know can't work all the time either (otherwise the virus problem would be decidable and we could then use it to solve the halting problem) so there could be exploits in the wild that elude such detection. as such we really should be regarding exploit detection testing that uses in-house exploits on equal footing as virus detection testing that uses lab-made viruses.

what is a vulnerability

a vulnerability is generally considered to be a mistake or oversight that allows the vulnerable program or system to behave in an unintended and undesirable way in response to a particular input.

alternatively, in the sense that the inputs a program accepts represent a language, a vulnerability is a condition where unanticipated functionality is exposed and can be called like a programming API by 'programs' written in the input language in question (otherwise known as exploits).

the occasional exposure of unwanted functionality is unfortunately pretty much an inevitability because the complexity of modern systems makes it next to impossible to anticipate all possible outcomes for all possible inputs. only the most trivial of programs can be made proof against this problem.

although vulnerabilities generally do occur as a result of a mistake or failure to anticipate something, it's also possible for undesirable functionality to be exposed intentionally. these are sometimes considered to be a kind of backdoor. however the vulnerability came about, the exposure of that functionality is unintended and undesirable to someone - be they the software vendor or the software consumer.

back to index

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.

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

lies, damn lies, and statistics

nruns (who, by the way, have a product designed to fix the problem they're playing chicken little over) are reporting that there are 800 vulnerabilities in anti-virus products...

that's a pretty scary number, isn't it? 800... wow...

but wait, that's not 800 vulnerabilities in your av product, or in my av product, that's the aggregate number across more or less all av products... when was the last time anyone reported an undifferentiated vulnerability metric for an entire class of software? when has that even been interesting the the past?

imagine how many vulnerabilities there are in operating systems - not just one operating system, but all of them combined... and while we're imagining this metric lets make sure that we count each distribution of linux independently, just so we can see how high we can make the metric go...

i wonder how many vulnerabilities there are in browsers or media players or word processors... not just individual products but the entire classes... again i'm sure the numbers are big - see how using browsers or media players or word processors become part of the problem? because that is one of the arguments nruns is making - security software increases the attack surface and therefore makes you less secure... something which obviously completely ignores the positive contributions they make to security - you need to examine both positive and negative contributions, folks... you have balanced a checkbook or budget at some point, right?

while we're examining things, lets examine the independent figures that nruns themselves point out... 50 security advisories for the period from 2002 to 2005, and 170 for the period from 2005 to 2007... first of all, this looks like growth but could just as easily be the result of increased focus on finding vulnerabilities in this class of software... second, 220 (170 + 50) is a far cry from 800... i'd be interested in knowing EXACTLY how that number was arrived at (since such knowledge is how one avoids being mislead by bad statistics)... is each vulnerability distinctly different? if 50 applications have the same vulnerability does it get counted 50 times? if the vulnerabilities were found by forensic analysis of binaries, were any vulnerabilities counted multiple times in the same product due to appearing in multiple places in the code? etc...

at a time when treating the av industry as security's whipping boy is at an all time high, such sensationalistic numbers probably make for good marketing for nrun's product, so long as people don't recognize it for the opportunistic FUD that it is... nruns has what sounds a bit like a scanner sandboxing product which on the face of it sounds like it might be a pretty good idea, but they clearly have a vested interest in making the av industry look bad (because that drives demand for their product) so even if you don't believe the 800 vulnerabilities figure is intentionally poorly defined or an example of opportunistic FUD, you should at least recognize that it's a figure that should be taken with more than a few grains of salt...

vulnerability research vs. malware research

well, i said i was tempted to write a post on this topic, and even though it turns out i've written about it several times in the past (viruses and disclosure, malware and disclosure, full disclosure to name but a few) i'm going to try it again in hopes that after this one i won't ever have to repeat myself on this subject again (yeah, as if)...

as always, the most interesting debates wind up being about meaning, so lets define some terms for the sake of this discussion... a vulnerability is in essence a mistake that allows a component or service of a system to behave in an unexpected and unintended way that has a negative impact on the security of the system (i know not everyone ascribes to the mistake definition, but it's useful to draw a distinction between those vulnerabilities which can be fixed and those that can't - rest assured i will cover the alternative later)... vulnerability research, then, is the process of discovering these mistakes; sometimes by looking at source code, sometimes by reverse engineering the vulnerable system, sometimes even by accidentally or intentionally triggering the unintended behaviour... now there's a pretty broad consensus (with the exception of the bad guys) that vulnerabilities are bad so naturally we want to get rid of them, and because they're mistakes they can be fixed... however, because vulnerability research is often performed by people other than those who made the vulnerable system in the first place, it becomes necessary to find a way to demonstrate the existence of the vulnerability to others... further, those tasked with fixing the vulnerability require a reliable means of triggering the unintended behaviour in order to determine why that behaviour occurs and in order to ensure that whatever fix they put in place actually fixes the vulnerability... therefore we need an exploit to trigger the unintended behaviour so that the vulnerability can be demonstrated to others to convince them that a fix is needed, and also to test for the presence of the vulnerability when developing (or even applying) a fix...

of course with those uses in mind it's important to make the distinction that what we want in the way of exploits are actually benign exploits (as opposed to malicious/weaponized ones)... for example, when dealing with an arbitrary code execution vulnerability, an exploit that launches notepad is preferable to one that launches tftp with command line parameters to download something malicious from the internet and then subsequently launch that... you see exploits can be used for malicious purposes as well as the positive ones already described, and the less benign the exploit is the easier it is for a bad guy to do something bad with it...

now so far i've described exploits as things that are able to demonstrate the existence of a mistake that we want to fix... clearly when that mistake isn't present the exploit shouldn't work so we can say that the exploit depends on the existence of the mistake/vulnerability...

malware is a different beast entirely because it doesn't (in general) depend on the existence of a mistake or vulnerability... what does it depend on? well, from one of the seminal pieces of research on viruses we know that self-replicating malware depends on 3 things: the ability to share data (necessary for the attacker to get his malicious software from his own machine to the victim's machine), the ability to pass data that's been shared with you along to others (sharing transitivity - necessary for self-replicating malware to spread or pass itself along), and the ability to interpret data that's been shared with you as program code (ie. the ability to add to or change the set of things the computer is willing to execute - the generality of interpretation - necessary for the computer to be able to execute the new incoming malware)... none of these things can really be considered flaws or mistakes, in fact it's hard to imagine computers being as useful as they are without them... without sharing there would be no internet, no floppy/cd/dvd drives or printers (they would allow sharing over the sneakernet), no store-bought software (you'd have to make all the software, including the operating system, yourself), etc... not being able to pass anything along would be equally bizarre (though that's the world that hollywood envisions and tries to make real through the use of DRM), it would also make the division of labour very hard to manage because hierarchies would be impossible (your boss wouldn't be able to pass along to you anything his boss had given him, nor would he be able to pass along to his boss anything you had produced)... not being able to interpret data as program code would be the most profound change of all as it is this property that makes the general purpose computer a general purpose computer rather than a pocket calculator - it allows a single computer to be flexible enough to be used for many changing purposes and without that flexibility we'd need a different piece of hardware specially designed for each and every new task that came our way... it should be clear that these are things we neither can nor want to 'fix' and so self-replicating malware will always be possible... it turns out that all sharing transitivity does for self-replicating malware is allow it to spread, so we can therefore say that in general non-replicative malware doesn't need it (though that doesn't necessarily mean some specific instances won't use it, such as for the command and control of more sophisticated botnets)... there are no additional dependencies worth mentioning for non-replicative malware in general (the exception being exploits, which can be considered a type of malware and obviously depend on vulnerabilities) because the underlying functionality they use is the same functionality used by normal software, it's just that that functionality is used to perform actions we don't want performed... communicating with a remote site the way RATs, botnets, and spyware does is just sharing of messages, and we've already covered sharing... writing to the hard disk is pretty fundamental and can even be considered a kind of sharing between sessions or a prerequisite of media-based sharing... outputting to the screen (something adware necessarily has to do) is necessary in order for the user to properly interact with the computer (and really all input and output can be considered as falling under the umbrella of sharing)... since there are no dependencies in general that can be 'fixed', this case therefore covers the alternative of the vulnerability that isn't a mistake...

now a clever reader at this point would be asking him/herself how much sense it makes to perform the previously described type of vulnerability research on a vulnerability that can't be fixed... a knowledgeable reader would know the answer: it doesn't make sense to perform that sort of research... an argumentative reader might point out that such malware can exploit fixable vulnerabilities too, but the answer to that is to research the fixable vulnerability and look at the exploit for that on its own rather than connected to more general malware...

so how does that change the nature of research around malware? well for one thing the previously discussed benefits of creating benign exploits don't apply in malware research because they were all predicated on the idea that what allowed the thing to exist could be fixed... we know that's not generally true for malware and in the cases where it is true it's because the malware contains an exploit that can exist separate from the malware and be used that way instead of connected to the malware (which only serves to make the exploit less benign)... additionally, because malware in general depends on non-fixable properties of a system (not to mention they're less benign), the benefits that society reaps from sharing benign exploits with the public at large also don't apply to malware for essentially the same reason...

another, more intrinsic difference between the two research fields is that in vulnerability research we create a special kind of malware called exploits as indicators of the presence of the vulnerability but in malware research we do not create any kind of malware as an indicator of the presence of malware (that just wouldn't make sense)... creating malware in the course of doing malware research would actually be analogous to creating vulnerabilities in the course of doing vulnerability research... the reason we create indicators for vulnerabilities is that the vulnerabilities themselves are not exactly visible or shareable, they aren't distinct entities in and of themselves, whereas if i want to show you a piece of malware i give you the actual malware...

a third difference between the two research fields is that there is (according to popular informed opinion) a discrete, finite number of vulnerabilities while the number of possible malware is, theoretically, countably infinite - limited in practice only by the available storage space... so while it may make a certain kind of sense to enumerate vulnerabilities, making an exploit for each one so that the vulnerability can be mitigated (hopefully before it gets used by the bad guys), it's a very different idea to try and enumerate all possible malware in hopes of being able to mitigate all of them (because there's just too many of them and because there are so many, most will actually never actually be made by either the good guys or the bad guys)... furthermore, while it might seem feasible (or at least within the realm of hope) to stay ahead of the bad guys with regards to vulnerabilities, no matter how many pieces of malware we preemptively make in order to mitigate them the chances that we will block a bad guy by beating him to the creation of a particular piece of malware is essentially zero... the malware we might make is practically guaranteed to be different from the malware the bad guys will make...

by now you should be starting to see how different malware research is from vulnerability research and how pointless creating malware for the purposes of malware research is compared to creating benign exploits for the purposes of vulnerability research... instead, malware research focuses on malware that has already been made and classes of malware that already exist... rather than creating malware and hoping in vain that the bad guys malware will have the same properties, malware researchers share data with each other about new malware trends while they're still in their early stages and make educated guesses about what the next step will be... sometimes their predictions are right (such as storm botnet nodes being used in phishing, which was predicted when it was observed that the botnet was becoming segmented) and sometimes they aren't (or at least aren't yet, like some of the more ambitious predictions about mobile malware)... as such, malware researchers also look at the human attackers creating/using the malware - trying to guess their motivations, gaging their skill level, determining their connections with others, etc, because all those things are important in predicting what they might do next... enumerating possible future malware is not nearly as useful or accurate as a predictive tool in malware research as it's counterpart is in vulnerability research...

given these profound differences, it really makes very little sense to treat malware research the same as vulnerability research or malware in general the same as a benign exploit...

follow-up on the ethical conflict in the webappsec domain

well, it's been several days now and there have been a number of reactions (such as the comment thread for the article i originally linked to or christofer hoff's reaction to my previous post on the subject)...

i wanted to post a follow-up to address robert hansen's reaction to my post and i was actually planning on posting it sooner but now i'm glad i didn't because i get to throw in material from mike rothman as well...

i'm going to start with mike, actually, since i can at least link to what he wrote (though past experience trying to comment on his blog has been less than stellar - ie. the comments seem to get lost)... mike posted his reaction in today's daily incite and although he thinks he knows what my argument is about he actually gets it rather spectacularly wrong...

Kurt thinks that this is going to uncover an attack that wouldn't have been discovered otherwise and that's a bad thing.

no, i think that the contest is going to a) create new threat agents (ie. worms - that is the point of the contest after all) and b) popularize this class of threat...

creating threats, increasing the total number of threats out there is not something white hats are supposed to be doing... that contributes to the problem, not the solution...

popularizing the threat means that the bad guys' adoption of this class of threat agent will speed up, in other words the arrival of xss worms and other web-based malware (which are probably an inevitability given our current trend towards web-based computing) happen sooner...

both of which ultimately benefit mr. hansen...

That we shouldn't trust these researchers because they think like hackers.

no, we shouldn't trust them because they act like bad guys... creating malware and/or requesting the creation of malware is fundamentally not a white hat activity because it contributes to the malware problem (the way dropping litter on a littered street contributes to the litter problem)...

My point is that in all likelihood they are working on smaller footprint and more innovative XSS attacks and they are going to figure stuff out.

indeed they may well do so, but they sure as hell shouldn't receive help from us in order to get there...

So we need to engage in similar tactics to understand the attack surface and protect our stuff.

similar tactics? defense is not the same as attack, they don't use the same tactics - and even if it were appropriate to use tactics similar to the bad guys (and there's a serious question of how we differentiate ourselves from the bad guys if we do), the bad guys are NOT doing their research in the public sphere... they at least have the good sense to use darknet channels to avoid helping us... that is the tactic we should be copying...

How will we defend ourselves if we aren't doing similar research?

by analyzing threats rather than creating new ones... there is no real reason to expect the malware we write and the malware they write will be similar enough for defenses against our own malware to automatically work against theirs as well...

Kurt's entire argument is based on the assumption that the bad guys aren't going to figure the stuff out anyway.

and once again, spectacularly wrong... my argument is based on the principle of not being part of the problem... it doesn't matter if they figure this stuff out on their own or not, we shouldn't be helping them...

But playing the ostrich game and hoping the problem goes away doesn't work very well.

playing dumb and ignoring the unintended consequences of your own actions doesn't work very well either...

moving right along to robert hansen's reaction (which, for previously described reasons, i'm not comfortable linking to so the quotes will just have to be good enough):

Clearly, and admittedly most of these people have no background in the issue and have never read this site

and then there's me who both has a familiarity with worms and reads the site...

as there is lots of samples of existing worm code in lots of places on the Internet now. Just because they don’t know about it doesn’t mean it’s not there.

and just because it's out there doesn't mean you should add to it...

I’ve always said, you don’t understand a problem until you see it and play with it.

playing with malware and creating new malware are not on the same level...

If working to help the understanding of worm propagation makes me evil, so be it.

understanding may be the ends but those ends don't justify the means... not everything done under the banner of a laudable goal is alright...

I’d rather be evil and be able to help solve problems than be good and be useless at solving the problem

though i've never personally referred to mr. hansen as evil, his current path will make the problem worse, not better, and it most certainly won't solve the problem... worms are not a solvable problem...

Will this empower bad guys? I’d be nieve to say there’s no chance of that.

in truth some of the bad guys will gain at least as much knowledge from this experiment as the good guys will... further, the knowledge this produces will be directly usable by them, not us... the contest is advancing the art of xss worm creation (creating new threat agents is the job of the attacker, not the defender), with the intention that the results will be usable in a second stage of research into xss worm mitigation...

For people who liken me to an anti-virus company writing viruses,

i think the closest anyone came to making that comparison was me, but what i actually compared mr. hansen to to was an anti-virus vendor motivating others to create malware that would ultimately benefit that vendor... and i made that comparison because, with the exception that mr. hansen isn't an anti-virus vendor, that's exactly what's going on...

I’d like to point out the fact of the matter which is that I don’t get paid to consult with browser companies on browser security

fine, the browser companies don't pay him, but the companies hoping to avoid getting hit by xss worms (among other things) do... the more popular that threat becomes, the greater the chance such companies will get hit and therefore the greater the demand for his services...

To date I also have never been paid by any company who has ever been hit by an XSS worm.

yeah "to date"... that's because the number is still relatively low... but as i said, he does get paid by companies hoping to avoid that fate...

Also, unlike an anti-virus company, I don’t have a security product in development.

instead he has services and a brand and who knows what he'll be able to leverage that into in the future... jamie butler wasn't part of an anti-stealthkit company when he was writing and popularizing stealthkits - it wasn't until later that he became the CTO of a government funded anti-stealthkit startup aiming to solve the problem he helped create...

Think the bad guys are going to stop their own research if we stop talking about it?

no, i just think they won't get a helping hand anymore... or has the idea of not being part of the problem gone out of fashion?

But through it all, I’m 100% confident that this will lead to previously non-published/understood results about worm propagation

and i'm 100% confident that he will hasten the onset of the web-based malware problem by popularizing it as he does...

Time to start working on solutions, rather than trying to keep the research quiet.

said as if those two things were mutually exclusive... they aren't...

and of course there were numerous comments in support of mr. hansen's actions... from christofer hoff:

I found it rather interesting that Kurt took the tact that he did. I think his point regarding the potential for misuse of code generated as a result of the contest is plausible but unlikely.

it was also the lesser of the two issues i was bringing up... however, since the bad guys have shown that they are in fact willing to use proof of concept code written by the good guys (see: bootroot) it's still something one should take seriously...

Honestly, PoC code for any sort of exploitable vulnerability has the potential for misuse, so I’m not convinced this is a corner case that deserves the flambe treatment it’s getting.

apparently i'm going to have to get used to saying 'except these are worms, not just exploits' (because i already said it a couple times on hoff's own blog)...

However, I found it a bit of a reach to accuse you of ethical violations and seeding the world with Malware so you could profit from the results as part of a giant conspiracy theory.

i didn't say he was seeding the world with malware, i said he was increasing the xss worm's mindshare... this contest does increase the raw number of xss worms, but it's worst impact is that it captures the imagination of more bad guys and makes them more apt to jump into this problem space sooner...

It’s clear that many of those posting their opinions fail to recognize which side of the fence you sit and the contributions toward making the world “better” you have made.

the side of the fence on which he intends to sit and the one he winds up on are not necessarily the same thing... the road to hell is said to be paved with good intentions after all... whatever contributions he may have made, they have to be taken in context of how they were made...

from digi7al64:

Also in response to this from Dr. Vesselin Bontchev who stated “Respectable security researchers don’t encourage the creation of malware by running contests for it!”. Sir, I don’t believe that a single entity of peers should be solely those with the knowledge to determine who and when the general public should be “allowed” this type of information.

and the reason s/he (sorry, but the pseudonym does not convey a definite gender) believes that is because s/he is either naive, believes malware research is the same as vulnerability research, or is ignorant of malware research/creation history...

malware materials belong in the hands of the public about as much as infectious biological disease samples do...

from someone calling themselves spyware:

Hiding the problem instead of stopping it? What are we, scared? Afraid for the consequences? Act NOW and you are safe.

this person is obviously someone who believes xss worms can be stopped once and for all (thereby making one 'safe')... that's not going to happen unless xss itself can be wiped out (which doesn't require worm research much less worm creation) or unless the entire web regresses to purely static content...

the ability to support malware such as worms and viruses an inherent property (rather than a flaw that can be corrected) of any system where sharing is allowed, where that sharing is transitive (what i share with you, you can share with others), and where data can be interpreted as program code... nothing in the particular implementations or even in larger patterns one sees in groups of implementations of xss worms is ultimately going to be able to stop xss worms once and for all - only stopping xss itself or all active content stops those things which allow xss worms to be...

from the very briefly named xs:

Education should never be considered unethical.

education at the expense of others may well be unethical depending on the nature of that expense...

and from robert (presumably a different robert than mr. hansen who prefers to go by the pseudonym rsnake):

Security Through Obscurity has never been a good approach,

relying on obscurity for your security is not a good approach, but there are plenty of things for which removing obscurity does not help you...

for example, you would not benefit if your personal details (full name, mailing address, telephone number, financial information, etc) became less obscure...

and that's where things stood the last time i checked... nobody (and i mean nobody) seems to get the argument about the contest leading to the threat class entering the mainstream sooner... mr. hansen came closest when he disingenuously tried to refute the argument that he stood to gain from the problem becoming worse... but the real head scratcher, the thing that i've found most frustrating of all is how people like to apply vulnerability research logic to malware research issues... i'm actually tempted to write a new post specifically about just that...

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

the final word on crazy world

so it's come to this has it? guillermito was found guilty and his appeal failed... he's got to pay big bucks because tegam didn't like being made fools of... well, i hope tegam gets their money's worth because the streisand effect generally doesn't work in favour of those trying to cover things up...

there's really nothing left to say about it though... it's over... tegam 'won', the people of france lost, and security research in that country will never be the same... pretty sad, really...

how to spot snake oil using the halting problem

i blogged previously about how the halting problem is good for separating the possible from the impossible in the malware field, but i suspect it's still a little over most people's heads... art kopp came up with the term "snake oil spotter guidelines" and it inspired me to try and distill what i said earlier into a (hopefully) simpler heuristic that anyone can use...

let's say you have a sequence of one or more bits or bytes... let's further say that it's of finite length (in practice we never deal with anything that goes on for ever) and that it is well defined (we know the exact sequence)... this might sound familiar, it might even sound like a virus signature, but i'm talking in a much more general sense here so we'll just call it a pattern...

1. any system that claims to find all instances of something that is equal to or contains such a pattern (ie. finding all instances of the character 'a' or the string "dog") does not run into difficulties with the halting problem and is not snake oil (at least not as far as that particular claim is concerned)...


2. any system that claims to find all instances of something that is not equal to or does not contain such a pattern (ie. finding all instances of a characters that aren't 'a' or all words that don't contain the substring "dog") does not run into difficulties with the halting problem and is not snake oil (as far as that claim is concerned)...


3. any system that claims to find all instances of something using the equal/not equal or contains/not contains comparison to any one of a finite list of such patterns (ie. finding all instances of the characters 'a' and 'b' or all words that don't contain the substring "dog" or "shoe") does not run into difficulties with the halting problem and is therefore not snake oil as far as that claim is concerned...


4. any system that claims to find all instances of something less trivial than what has been described so far, something that can't be represented as a well defined finite set of such patterns (viruses, for example, cannot be represented that way as there are an infinite number of possible viruses - so too with any function, since there are an infinite number of ways to implement any given function - also any class of bug or vulnerability has an infinite number of ways in which it can occur in practice), or by using a less trivial method of comparison (certain types of preprocessing, like decryption or decompression notwithstanding) generally does run into difficulties with the halting problem and therefore probably is snake oil...


5. any system that claims to prevent or avoid all instances of something must use a technique that is equally capable of finding all instances of that something and so the previous rules apply...


6. any system that only claims to find/prevent some instances of something doesn't run into difficulties with the halting problem and is therefore probably not snake oil as far as that claim is concerned...

wow, that's actually pretty big... let's condense it...

any system that claims to find all instances of something and that something is non-trivial and/or is to be found using a non-trivial comparison method will generally run into difficulties with the halting problem and therefore be snake oil...

as a corollary to the above, all real world threats and vulnerabilities wouldn't be problems if they were trivial... therefore any system that claims to find or prevent all instances of a particular kind of threat or vulnerability is snake oil unless the particular kind in question is specified narrowly enough that it applies only to a specific, well defined, finite set of items that can themselves be represented by one or more of a finite number of the above mentioned patterns... for example, all known viruses represents just such a set of items and can therefore be detected and/or prevented without running into problems with the halting problem...

microsoft antivirus: the next generation

by now you've probably heard that microsoft plans to get into the anti-virus industry (again) and has already entered the anti-spyware industry... they apparently are planning to release a complete security package for a fee (see Techdirt)...

now, Techdirt makes an interesting argument for why giving away the security package might be problematic for microsoft - that they might get accused of anti-trust violations with regard to the desktop security industry...

so it would seem that they can't not charge money for their product - but here's a different angle... a big part of the problem that their product will be addressing is the insecurity of their other products... the argument has been made that anti-virus companies are the ones behind the viruses and it's an easy argument to debunk (the industry is very competitive and the companies would use that information against their competitors if it were true), but when it comes to security exploits microsoft IS behind many of the vulnerabilities being exploited... they're basically charging you to protect you from the threats posed by their other software - which sounds an aweful lot like a protection racket to me...

worse still, however, is that with their complete security package they would have less motivation to actually fix the security problems in their other software... they could say that the threat posed by vulnerability X is mitigated by Microsoft Security Suite (tm), so the severity of the problem is less than critical so fixing it will be a lesser priority... they've been trying to address security for years now and so far it's been an abject failure - we have no greater confidence in the security of their software now than we did when they started... this could mark the end of their efforts to write more secure code - it could be the sign that they're giving up... writing software to protect people from exploits when you should be fixing the vulnerabilities certainly sounds like a cop-out to me...

so really, there doesn't seem to be any moral highground for microsoft in this venture - either they kill the desktop security software industry by giving their own product away for free (like they did to netscape), or they can charge money for their product and at best admit defeat at writing secure code or at worst be guilty of protection racketeering...

maybe they should just stay out of the security industry entirely... they've tried their hand at it before (msav) and that was an abject failure too...

update from crazyworld

so guess what - Publishing exploit code ruled illegal in France...

guillermito will have to pay 5,000 euros if he publishes security vulnerabilities again... that's right, security research is basically illegal in france now so don't you be making fun of any of those french products that really, really suck...

but wait, there's more (there always is with this case)... if you read this article you'll see that tegam is defending it's actions by saying that guillermito's claims are false and his motives questionable... ooops! if his claims are false then the exploits he supposedly published must not actually exploit weaknesses in the product - in which case he didn't publish exploits, only defamatory material, in which case tegam's current claims against him are baseless... but since a court of law agreed with tegam's claims they must not be baseless, in which case the exploits are real, in which case his claims are true rather than false... you can't have your cake and eat it too, tegam...

i swear this company must be run by untrained monkeys...

more from crazyworld

f-secure's blog had 2 good links showing both supposed sides of the guillermito vs. tegam issue...

tegam's press release described their displeasure at having their company violently depreciated (violently? ok, maybe thats just a translation thing, but they're obviously trying to appeal to our emotions rather than logic) for years and how a hardheaded search for vulnerabilities (what might otherwise be called persistence) is somehow wrong and unfair and that other companies don't get treated that way (even though they do - one need only look as far as invircible and it's creator zvi netiv for an example of that; martin overton's chekmate didn't escape notice either, and there are plenty more examples)...

guillermito's side seems reasonably well laid out and unmired by marketing double-talk, along with examples (scanned full page advertisements) of tegam claiming he was a terrorist and that the FBI was looking for him...

tegam's press release suggests they're upset at the negative publicity guillermito has caused them, that it's hurt their public image, and yet they are the ones making false terrorist accusations... their legal complaint against guillermito doesn't seem to contest the validity of his claims, it only charges that he reverse engineered their product in a way that was not legal... you'd think if guillermito's claims about their software was false and that it hurt their reputation so much that there would be some sort of charge of defamation or something... i suppose guillermito must have a strong defence against such a defamation charge (like his claims being the truth)...

tegam - stop being such petulant children and take responsibility for your failures...

and in crazyworld, people can go to jail for finding bugs... did i say crazyworld? i meant france...

on fark this would probably get the [Asinine] tag... if you haven't heard about guillermito vs. tegam then count yourself lucky for the bliss that is your ignorance...

long story short: tegam produced a very, very bad anti-virus product, called viguard, and made classic snake-oil claims... guillermito (ok, not his real name but i always go by the first name i know a person by) produces a report that documents how bad the anti-virus is, complete with exploits... tegam sues guillermito for counterfeiting/criminal copyright infringement... guillermito faces 4 months probation in france (kind of a long way to go to see your probation officer when you currently live in the states and are working at harvard - assuming probation works in a similar fashion there) and a hefty fine...

what is the moral of this story? do you think it's that you should keep your mouth shut when companies LIE to the public? do you think it's that france's justice system is borked?

no, the moral of this story is that tegam cannot silence criticism with lawyers - the publicity from this case will point everyone towards the truth - any possibility of them re-establishing secrecy for their product's problems is gone - the only purpose the lawsuit can serve is to punish someone for telling the truth - and on the internet things have a habit of never going away, ever...

the free market works best in the presence of an informed consumer... tegam may win in a court of law, but the court of public opinion is a different beast entirely... vote with your wallet, folks...

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

IDG News Service gets it wrong

it's a short article, give it a read..

InfoWorld: First Windows CE virus emerges: July 19, 2004: By : APPLICATION_DEVELOPMENT : SECURITY

notice right at the beginning how it says the new WinCE virus was designed to demonstrate security holes in the WinCE operating system? this is a subtle point, one that far too many people fail to grasp, but the ability of viruses to infect a platform has nothing to with security holes in that platform... virus infectability is a 'feature' of all general purpose computing platforms... *all of them*... you can't create a general purpose computing platform that isn't susceptible to viruses...

therefore you cannot (as the article's author does) infer security holes in an OS simply because the system is vulnerable to viral infection... it's a shame mass media doesn't have a better grasp on what they're talking about when they're talking about viruses... this one article is being picked up by a number of tech related news sites, spreading this rubbish far and wide...