the folly of offensive cyberwarfare

i often feel like i can't speak freely about cyberwarfare (due almost entirely to my principles about not helping or giving ideas to those who make things worse, be they criminals or warmongers), but it's hard to deny the importance of the subject, and frankly when i read what others have written i can't help but think they haven't really thought things through very well.

when it comes to the development and use of digital weapons there are a couple of key points whose implications need to be understood and kept in mind. the first of these is the problem of attribution. the difficulty in attributing the source of a computer attack is both tactically advantageous, and strategically constraining. the advantages should be obvious - you can attack an opponent without the opponent knowing who is responsible for the attack (unless you screw up and reveal yourself). the problems begin, however, when you consider that the opposite is also true - one or more of your opponents can attack you without you being able to tell who it was.

consider what that means. if you can't tell who is attacking you, how can you possibly retaliate? imagine you're blindfolded, you're ears are plugged, you're handed a gun, and stuck in a room with other people who may or may not also have blindfolds, earplugs, and guns. if someone starts shooting at you, how can you realistically return fire to defend yourself without knowing where to shoot? without the ability to target the your opponent you cannot retaliate, you cannot end him before he ends you. further, when the threat of retaliation becomes empty like this, deterrence no longer works. as a result, so-called cyberweapons have no defensive value.

in the absence of attribution, a conflict must consist entirely of first strikes. there is no retaliation, there is no deterrence, there is no scaring an enemy off by showing what you can do, there is no point to visibly stockpiling armaments. that is significantly different from most conventional models of warfare. this is one of the reasons why cyberwarfare must only ever accompany traditional warfare - only then can combatants avoid firing blindly in the dark.

another important aspect of digital weapons to keep in mind is the fact that they're digital. they're code, bits and bytes inside a computer. what is the one thing computers are exceptionally good at doing with those bits and bytes? copying them. imagine a world where it's expensive to develop guns and tanks and bombs from scratch, but it costs virtually nothing to copy them. that is the world of cyberwarfare, and that is a world that actually does not favour the attacker, per se, but rather one that favours the forager (one of the things sun tzu teaches is to forage on the enemy) because s/he gets the most benefit (a sophisticated digital weapon) for the least cost.

when weapons cost a lot to develop from scratch but very little to copy, what conditions do you suppose would make their development and use make sense? if you could eliminate the possibility of copying and re-use, if the weapon assured you a decisive victory over your opponent then it wouldn't matter that it would be falling into your opponent's hands simply by you using it. unfortunately in the real world a nation has many opponents. they cannot all be fought at once and so a decisive victory against all whose hands such a weapon may fall into is not possible. 

what's more, not all of those opponents are necessarily other nation states. the low cost of copying weapons means that the barrier to entry on this battlefield is lowered and more mundane opponents like terrorists or even sophisticated criminals can join the fray. as you can well imagine, those kinds of opponents are far less disciplined and restrained than a nation state would be.

our best example of a digital weapon thus far is stuxnet. it's believed to have cost millions of dollars and many man-years of effort to develop, and now anyone who wants a copy can download it for free from the internet. i would be remiss if i failed to point out that by now stuxnet is pretty well neutered (since the windows vulnerabilities it exploited have been patched and most anti-malware will detect it's presence) and it would actually take a fair bit of time and money to replace the neutered bits so it could be re-used; but there was a time before that was true when stuxnet was still in many people's hands and could have been re-used at a much lower cost. as strange as it may sound, the malware's discovery and subsequent neutering actually served to mitigate the potential for it's re-use. it's creators are lucky it happened before the malware could be re-used against them, their allies, or other interests they might have. that might not be the case next time.

it's a peculiar irony that the people most capable of developing digital weaponry (the technologically advanced and dependent) are the same people who have the most to lose if such weaponry is used against them. this should make it obvious that defense, not offense, is where one's money and effort would better spent. just so i'm not that guy who makes overly general, hand-wavy suggestions, here are some ideas that are more specific than just "you should do defense":

• fault tolerant designs
• redundancy is already something we know how to do, but we don't always do it well (as the 2003 blackout clearly demonstrated). the internet is said to be so fault tolerant that if part of it goes down the rest will just route around it. there are many paths to the same destination. obviously that's a property we want for power, communications, water, etc. it's something we should be designing for and unfortunately because it costs it's something we need to pay for. 
• ease of recovery is something we perhaps don't think quite as much about. how easy is it to replace physical equipment that no longer operates as intended? how easy is it to overwrite logical systems from backups? how many minutes, hours, or days does it take? aiming to minimize that time also serves to minimize the impact of anything unfortunate happening to the system in question.
• system hardening
• vulnerability research and patching is something that already enjoys a certain measure of success in consumer and enterprise environments. if a nation wants to protect it's critical infrastructure then perhaps more money and energy should be poured into researching vulnerabilities in that critical infrastructure.
• eliminating or rethinking external connections (including both network connections as well as removable media) basically stands in direct opposition to the trend of hooking more and more of our most important systems up to one of the most dangerous networks on the planet (the internet). as with most things, the business incentives that are driving the current trend need to be accounted for. the cost saving benefits of remote connections are understood, but there are other ways of achieving that goal without resorting to the internet - that's simply the cheapest/easiest option
• whitelisting of code and possibly even data on critical infrastructure systems, because quite frankly why should new unknown material be introduced to these systems? it may make sense to occasionally and in a very controlled way apply fixes or make changes corresponding to changes in the industrial processes those systems are a part of, but in general those machines should be unchanging and that should probably be enforced. as a corollary, eliminating dual use is probably a good idea too. there's no reason you should be writing your TPS report on a machine that can control whether the lights stay on. 
• early warning detection
• while some may argue otherwise, training of personnel actually can work and i can think of no better example of this right now than the recent case of a planted malware-laden USB flash drive that an employee decided was suspicious an took directly to IT.
• sensors within protected systems performing things like integrity monitoring (to help minimize and scrutinize changes to those systems), behavioural profiling of software components, logging, etc.
• evasion
• disinformation can be useful in a couple of ways. it can raise the cost of successfully performing an attack by tricking the attacker into doing useless things, and it can also trick the attacker into doing something that sets off an alarm (ie. they walk into a trap).
• decoy systems that look and act for all intents and purposes just like the real ones can reduce the impact and success of attacks, especially if they have the same warning sensors the production systems do, by turning the problem of attacking the right system into a game of chance for the attacker. holding out baits for the attacker to reveal their presence and/or intentions can certainly confer advantages on a defender.

i've made a few veiled (and not so veiled) references to sun tzu. while some people may argue that "the art of war" is over-played and not particularly relevant to information security, when it comes to warfare of any kind i think it's very relevant:

Sun Tzu said: The good fighters of old first put themselves beyond the possibility of defeat, and then waited for an opportunity of defeating the enemy.

that is to say, of course, that we need to take up a defensible position first before we start attacking. by most accounts (including president obama's) we aren't there yet.

flame's impact on trust

if you haven't watched it yet, i encourage you to check out the video of chris soghoian's talk at personal democracy forum 2012. the TL;DR version is that, because it compromised the microsoft update channel, the flame worm damaged our trust in automatic updates and that's a bad thing because automatic updates have done so much good for consumer security. mikko hypponen is even reported to be planning to write a letter to barack obama to ask him to stop the US government from doing this sort of thing again.

unfortunately, i think this is short-sighted, and not just because you can't put the genie back in the bottle.

inherent in the idea of automatic software updates is this little thing called automatic execution. i've written before about how problematic automatic execution can be. it all comes down to delegating a security decision (to execute or not to execute) to an automaton, and fooling an automaton has never been considered difficult. this particular example might be one of the most difficult cases of pulling the wool over a machine's eyes there is, and yet it was still done and done in a big, headline-making way. an automaton may be more consistent about how it does things than ordinary people are, but that may not necessarily be a good thing for security. being consistent and predictable is, no doubt, part of what makes an automaton easier to fool than a person.

the trust we placed in automatic updates was, if not completely misplaced, then at least partially misplaced. microsoft may have made it harder to fool their code again, but i doubt every other software vendor in the world has put an equivalent amount of time and engineering effort into their own update security - some (many?) are probably within the realm of what more traditional cybercriminals can exploit.

we placed trust in microsoft's code, in the automaton they designed, not because it was trustworthy, but because it was more convenient than being forced to make the equivalent decisions ourselves. furthermore, we relied on it for protecting consumers because it's easier than educating them (in fact many still don't believe this can or should be done). it can certainly be argued that we can't rely on consumers to make good security decisions all the time, but clearly we can't rely on automatons to do it either. a lot of effort has been put into developing controls to prevent bad things from getting through, but what has been done with regards to detecting when those preventative controls fail? not a heck of a lot, and i don't have a lot of confidence in the idea of creating a second automaton to spot the failings of the first.

if the trust we had in automatic updates is fading then let it fade. we never should have been trusting it as much as we were in the first place. maybe, with more reasonable limits on that trust, we can begin to develop more meaningful countermeasures for attacks exploiting this particular brand of automatic execution (and it's important that we do so, because attacks only ever get better).

correcting a rebuttal

so if you haven't read it yet, mikko hypponen wrote a non-apology for why his company and companies like his failed to catch the flame worm. in response, attrition.org's jericho wrote a rebuttal, taking mikko to task for the perceived bullshit in the aforementioned non-apology. while i think his heart was in the right place, a number of the specific criticisms jericho makes are unfortunately based on an understanding of the AV industry that is too shallow.

When we went digging through our archive for related samples of malware, we were surprised to find that we already had samples of Flame, dating back to 2010 and 2011, that we were unaware we possessed.

In the second paragraph of this bizarre apology letter, Mikko Hypponen clearly states that the antivirus company he works for found or detected Flame, as far back as 2010. In this very same article, he goes on to say that F-Secure and the antivirus industry failed to detect Flame three times, while saying that they simply can't detect malware like Flame. Huh? How did he miss this glaring contradiction? How did Wired editors miss this?

i can tell you right now how this apparent contradiction isn't actually a contradiction at all. AV companies receive many submissions per day, more than can possibly be examined by humans, and a great many of those submissions are not actually malware. AV companies use automated processes* that they develop in-house to determine if a sample is likely to be malware or not and (if possible) what malware family it belongs to. not everything that goes through these automated processes gets flagged as malware and that technical failure to recognize the sample as malware 2 years ago is almost certainly the failure that mikko was trying to explain. they still keep the sample, mind you, even though they don't have reason to believe it's malware, and that's how mikko was able to find it in their archives.

(* those automated processes can't easily be distributed for customer use, by the way, as they require too much expertise to use, not to mention too much data as a comparison against a large corpus of other known malware is part of those processes)

really, when you think about it, if they'd known it was malware 2 years ago, they'd have added detection for it (even if they didn't look any closer - adding detection is also largely automated, especially for something that doesn't try to obscure itself or otherwise make the AV analyst's job harder) and then would have trumpeted the fact that they've been protecting their customers from this threat for years when it was finally revealed what a big deal it was. i think we've all seen this scenario play out before, and it would certainly serve their business goals better than admitting failure would.

hopefully this explains why this sort of rage...

Rage. Epic levels of rage at how bad this spin doctoring attempt is, and how fucking stupid you sound. YOU DETECTED THE GOD DAMN MALWARE. IT WAS SITTING IN YOUR REPOSITORY.

... is misplaced.

 It wasn't the first time this has happened, either. Stuxnet went undetected for more than a year after it was unleashed in the wild, and was only discovered after an antivirus firm in Belarus was called in to look at machines in Iran that were having problems.

For those of us in the world of security, hearing an antivirus company say "we missed detecting malware" isn't funny, because the joke is so old and so very tragically true. The entire business is based on a reactionary model, where bad guys write malware, and AV companies write signatures sometime after it. For those infected by the malware, it's too little too late. It's like a couple of really inept bodyguards, who stand next to you while you're getting beaten up and say, "I will remember that guy's face next time and ask management to not let him in." Welcome to the world of antivirus.

this frustration is something i see coming from a lot of security professionals. unfortunately the truth is that there are technical and theoretical limitations on what can be done with "detection". it frustrates me that others can't seem to recognize and accept this fact. detection requires knowledge of what one is looking for, whether that be a binary or a behaviour or something else. you can't look for something without knowing something about what you're looking for.

while it is true that AV vendors claim their products have heuristics - technology that can detect as yet unknown malware - that is still based on knowledge gained from past malware. it's reasonably well suited to detecting derivative work, but anything truly novel (and stuxnet certainly was that) is going to get through.

 When researchers dug back through their archives for anything similar to Stuxnet, they found that a zero-day exploit that was used in Stuxnet had been used before with another piece of malware, but had never been noticed at the time.

This statement is a red herring Mikko. Stuxnet used five vulnerabilities, only one of which was 0-day. One local privilege escalation used in Stuxnet was unknown at the time, the rest were documented vulnerabilities. If your excuse for the AV industry is that Stuxnet wasn't detected because it used a 0-day, your argument falls flat in that you should have detected the other three code execution / privilege escalation vulnerabilities (the fifth being default credentials).

a couple things wrong with this. first, what i think jericho meant to say is that AV should have detected the exploits rather than the vulnerabilities, as the vulnerabilities weren't in stuxnet but rather in the software that stuxnet was attacking.

second, as the provided chart clearly indicates, the disclosure date for 4 of the 5 vulnerabilities is after the discovery date for stuxnet (2010-06-17). i'm pretty sure that means the only previously documented  vulnerability was the default password. either that or jericho is actually right and simply using poor/contradictory evidence to back up his point.

finally, and probably more to the point, mikko wasn't offering the 0-day exploit as an excuse for why AV failed to detect stuxnet. he was pointing to it as a previous example of something being missed despite part or all of it being in their archives. he was trying to explain how just because something is in their archives that doesn't mean they are aware of it's significance. try thinking of AV vendors as being like pack rats - the only reason they'd throw something away is if they've already got a copy of it (and even then, i'm not so sure).

 The fact that the malware evaded detection proves how well the attackers did their job.

Again, it didn't evade detection, according to Mikko Hypponen, Chief Blah Blah at an Antivirus Company. He said so in the second paragraph of an article I read. That said, the fact is antivirus companies miss hundreds of pedestrian malware samples every day. Is this because the authors did so well, or that your business model and detection capabilities are flawed? One could easily argue that they are intentionally so (reference that bit about 4 billion dollars).

and again, jericho misinterpreted that second paragraph. now as for AV missing hundreds of pedestrian malware samples a day, i suspect the number is much higher, but that it doesn't miss them for long. a great deal of malware can't be detected before signatures for it are added, and those signatures can't be added until after the vendors get a sample. what sets flame and stuxnet apart from those cases is the length of time the malware was in the wild before signatures got added to the AV products. is this a flaw? once again, you can't look for something if you don't know anything about what you're looking for. in the sense that such a limitation prevents the system from being perfect i suppose it could be considered a flaw; but show me something that is perfect - you can't, can you, because nothing is perfect.

 And instead of trying to protect their code with custom packers and obfuscation engines - which might have drawn suspicion to them - they hid in plain sight. In the case of Flame, the attackers used SQLite, SSH, SSL and LUA libraries that made the code look more like a business database system than a piece of malware.

Where to begin. First, custom packers and obfuscation engines have worked very well against antivirus software for a long time. I don't think that would have drawn any more suspicion. Second, Flame is 20 megs, around 20x more code than Stuxnet. In the world of antivirus, where you are usually scanning very small bits of obfuscated code, this should seem like a godsend. If it isn't using obfuscation, then what is the excuse for missing it? Are you really telling me that your industry is just now realizing the "hide in plain sight" method, in 2012?

first, while custom packers have worked well against the AV software that's distributed to customers, they don't work nearly as well against the processes, procedures, and techniques used by AV companies when processing sample submissions. as a result such custom packers only prevent detection at the customer's site for a relatively small amount of time (though obviously long enough for some customers to get pwned).

second, being huge and not obfuscated works against being recognized as malware precisely because it is so out of character for malware (and thus it's not just the AV industry that's just now realizing the "hide in plain sight" method). unless you're under the mistaken belief that AV companies still reverse engineer every sample they get each day (numbering in the tens of thousands, last i heard), it should be obvious how the lack of obfuscation provides no help in determining if something is malware.

 The truth is, consumer-grade antivirus products can't protect against targeted malware created by well-resourced nation-states with bulging budgets.

No, the truth is, consumer-grade antivirus can't protect against garden variety malware, but it can apparently detect the well-resourced nation-state malware. Oh, that makes me wonder, what do you offer that is better than consumer-grade? Other than a bigger price tag, does it do a better job detecting malware?  

it's actually the reverse of what jericho says here; AV tends to add detection for garden variety malware quickly (thus closing the window of opportunity for the malware to successfully compromise the AV's customers and consequently protecting most of them from it) while they tend to add detection for state-sponsored malware quite slowly (and thus not doing much to protect anyone from it initially). i specifically express this as tendencies because there are exceptions (unless the energizer RAT, which took 3 years for people to recognize, was actually state-sponsored and nobody bothered to say anything).

as for what else AV offers - there are tools (other than scanners) that typically aren't packaged with their consumer product because they require a higher level of technical expertise to operate than home users tend to have. IT folks in the enterprise are more likely to have the necessary know-how to use these tools. when mikko refers to consumer-grade anti-virus products in this context, he's talking about the technologies that require next to no knowledge to use, ones where the knowledge is baked in in the form of signatures. that kind of product isn't going to stand up well against nation-states. technologies which require more of the user, ones where it's the user him/herself looking for anomalies or where the user decides which code is safe to run or what programs should be allowed to do have a better chance of helping you defend yourself against a nation-state (at least when paired with a talented user of that technology).

 And the zero-day exploits used in these attacks are unknown to antivirus companies by definition.

And again, this is bullshit. Stuxnet had 3 known vulnerabilities (CVEs 2010-2568, 2010-3888/2010-3338, 2010-2729), 4 if you count the default credentials in SIMATIC that it could leverage (CVE 2010-2772). Flame apparently has 2 known vulnerabilities (CVEs 2010-2568, 2010-2729). Even worse, if antivirus companies had paid attention to these samples sitting in their archives, they may have ferreted out the vulnerabilities before they were eventually disclosed.

once again, i can't find any details suggesting these vulnerabilities associated with stuxnet were known before june 2010. i'm not doubting that that may be the case for one or more of them, i do seem to recall mention of something like that for a vulnerability exploited by stuxnet, but if it's in the documentation i can't find it.

also, once again, these pieces of malware had exploits for these vulnerabilities, not the vulnerabilities themselves. and even if the vulnerabilities were known, programmatically determining if an arbitrary program exploits a particular vulnerability is as reducible to the halting problem as programmatically determining if an arbitrary program self-replicates. if it's a known exploit it should be findable just as known-malware is findable, but otherwise don't hold your breath (unless you're willing to let it happen and detect it after the fact).

 As far as we can tell, before releasing their malicious codes to attack victims, the attackers tested them against all of the relevant antivirus products on the market to make sure that the malware wouldn't be detected.

Way to spin more Mikko. This is standard operating procedure for many malware writers. I believe VirusTotal is the first stop for many bad guys.

this may have been true once upon a time, but the way virustotal now shares their samples with vendors makes them a poor choice for doing malware q/a. and they've been sharing samples for quite some time now.

When a big malware event makes the news, it only helps you. Antivirus firms are the first to jump on the bandwagon claiming that more people need more antivirus software. They are the first to cry out that if everyone had their software, the computing world would be a much safer place. The reality? Even computers with antivirus software get popped by malware. They don't detect all of those banking trojans and email worms like you claimed in this article. They don't protect against the constant onslaught of new threats. Your industry, quite simply, has no reason to improve their detection routines.

as a matter of fact, the individual member companies in the industry have quite a compelling reason to improve their detection routines. AV companies may not need to be better than the bad guys, but they certainly need to try and be better than each other. to adapt the old adage, they aren't trying to outrun the bear, they're trying to outrun each other. they compete. do you think mcafee simply rolled over and accepted the number 2 market position and let symantec have #1? no of course not. they'll try and take that market share if they can and symantec meanwhile will try to hold on to their lead. part of that is done with marketing, but part of it is also done with technological advancement.

I remember in the early 90's, the next big thing in the land of viruses was polymorphing virus code. Antivirus vendors were developing "heuristics" that would detect this polymorphing code. In almost 20 years, how has the development of that gone? Obviously not stellar. Antivirus companies spend their time cataloging signatures of known malware, because that sells. "We detect 40 squirrelzillion viruses, buy our software!" What happened if you developed reliable heuristics and marketed it? "Buy our software, once, and the advanced heuristics can catch just about any malware!" There goes your business model. So of course you don't want to evolve, you want to wallow in your big pile of shit because it is warm and comfortable. You can ignore that overwhelming smell of shit that comes with your industry, because of the money. Don't believe me? Let's hear it from the pro:

actually, traditional polymorphism was attacked in a generic way through emulation. it worked pretty well, but has no effectiveness against server-side polymorphism due to lack of access to the server-side processes. as for developing reliable heuristics, why do you think malware writers perform malware q/a? their new pieces of malware will already evade known-malware scanners simply by virtue of not being known malware. the only reason to take that extra step of performing malware q/a is because the heuristics actually are fairly effective. what the the heuristics are not is perfect. they can be fooled (in some cases quite easily, but fooling an automaton has never been considered difficult). i suggested a heuristic countermeasure to malware q/a but i have no idea if anyone actually tried it.

i do think jericho has hit the nail on the head about evolving, though. what i don't think many people appreciate is the path which the industry's evolution needs to take. prevention is always going to have failures like what has happened with stuxnet or the flame worm or even the garden variety malware while it's still new. we as users need to grow up and start accepting that fact. there is no magical prevention fairy - if you're old enough to not believe in santa, the easter bunny, and the tooth fairy, then you're old enough to realize that prevention has limitations and always will have limitations.

the evolution that the industry needs to do is to help users come to terms with this fact and help them deal with it by providing tools for detecting preventative failures in addition to the tools they already provide for prevention. to a certain extent they already used to do this but those tools appear to have disappeared from the mainstream. at least a few vendors had integrity checkers back in the day. i remember one from kaspersky labs (which was painfully slow as i recall), and one from frisk software. i've long wondered (and have my suspicions about) what happened to wolfgang stiller because his product "integrity master" was excellent but . i believe adinf (advanced diskinfoscope) is still around but it's very much not part of the mainstream - most people would have never heard of it, and certainly wouldn't think to use it because it's not part of a larger AV suite (as most people have been trained to look for).

the strategy most people use to keep themselves safe is what they learn from the AV industry, but the industry mostly just tells them to use product X and product X is almost invariably prevention only (maybe with a dash of cleanup). it is probably the most simplistic and rudimentary strategy possible, but i don't hold much hope the AV industry will ever change that. in the process of teaching the public a more sophisticated security strategy they would in effect be making users more sophisticated and less susceptible to the marketing manipulations that vendors currently employ in their competition with each other. on top of that they'd have to stop using those manipulations themselves and risk losing their existing users to another vendor who hasn't stopped before they have a chance to make the users proof against those manipulations. the principles behind the PDR triad (prevention, detection, recovery) are foreign to most people, and among the rest many have perverted it into something almost as mindless as "just use X".

AV companies are businesses and like all businesses their primary concern is their own financial interests. those interests don't align with the security interests of their customers or the public at large and no amount of hand wringing or foot stomping is going to change that. i don't see any way that the industry can drive the change that's needed while serving their own interests, and i'm not going to hold my breath waiting for them to sacrifice their own interests for the common good. the AV industry responds to market demand and if you truly believe evolution is needed then it's beholden upon you to help build demand for tools and techniques that go beyond prevention.


(update 2012/06/03 5:11pm -  it appears that jericho has been remarkably responsive to comments from others on twitter so the rebuttal itself is in a state of flux. i'll have to wait and see how this turns out)

prediction vs. tempting fate

how many of you reading this remember conficker? i certainly remember it, but i have a long memory, especially when it comes to regrets. you may recall an apology i posted some years ago concerning the possibility that i might have made a small contribution to the feature-set of that malware by way of giving the bad guys ideas.

well, from where i sit, that may very well have happened again, only it wasn't me this time, it was an AV vendor. now you might expect that, as a result, said vendor may become much more scrupulous about censoring themselves. it's no easy task, let me tell you, but it's certainly something that some of you (and myself included) probably expect from the people who are supposed to be protecting us.

alternatively, you might expect just an apology, under the philosophy that it's better to ask forgiveness than permission. that would certainly be easier, although accepting responsibility for negative outcomes is not generally considered good for the public image of a company. as an individual, owning up to one's mistakes and accepting responsibility is considered a mark of maturity, but the rules for companies are unfortunately very different in this regard.

which brings us to the thing you might not have expected, but probably should have - bragging about it as though it were a "prediction":

that link, by the way, points to this story on informationweek.com which in turn points back to a post on the f-secure blog where it was suggested that if the people behind the flashback malware for the mac upgraded to unpatched java vulnerabilities (it had only been using exploits for old, already patched vulnerabilities before) they might affect a lot more people.

is that a prediction or an instruction? f-secure's blog, as you might be aware, is one of the most (perhaps the most) widely read blogs in the entire anti-malware field. it stands to reason that if the people behind flashback are reading any anti-malware blogs, that one is probably on their list. even if it isn't, that particular post was about their efforts and would most likely have been forwarded by someone who was aware of their work (just as, in a small software development company, every press release, news article, and TV spot that mentions your work gets sent to everyone in the company).

would they have upgraded to unpatched vulnerabilities without that suggestion being made? perhaps, perhaps not. we'll never know. do all malware profiteers who use exploits for patched vulnerabilities inevitably upgrade to ones for unpatched vulnerabilities? that's doubtful - exploits for unpatched vulnerabilities are much harder to come by than ones for vulnerabilities that have already been patched. the transition is anything but inevitable, so there exists the very real possibility that f-secure's "prediction" was more like a self-fulfilling prophesy.

but of course, it sounds better if you call it a prediction. it sounds like something that adds value to their voice (though they have plenty already without that) and so helps to build the brand.

it seems to me that openly predicting what the bad guys are going to do next, or speculating on what they could do better, only invites them to take your advice. you might then capitalize on that with liberal amounts of spin, but at the end of the day is giving them ideas really so much more benign than giving them code? don't you tempt fate either way?

to patch or not to patch: an edge case

i find myself in a rather odd predicament today. i've been using an older computer (we'll call it one of my secondary computers since it get very little use compared to the one i'm writing this with right now) and i got a pop-up notification that i was running out of space on drive C:.

now i want to put this in context; this computer sees very little use, mostly it gets turn on, has some files transferred to it or from it, and then switched off. i can't remember the last time i actually installed anything on it (for that matter, since i've switched over to using portable software, i can't recall the last time i installed anything on my primary system either) so let's say it's been a really, really long time since i touched the C: drive at all. mostly it's the larger secondary physical disk that gets used.

so you can imagine my surprise when the notification about running low on space popped up. was there something malicious going on? had the system been compromised? no, it was in the process of applying system updates. patches had actually eaten up the majority of my free space - the WINDOWS directory was taking up over 7 gigs of my 10 gig drive. i'm actually in the position where i have to uninstall software so that the patching will succeed.

now, this is an XP system so one might reasonably suggest that i upgrade to the latest version of windows so that i can avoid having all those patches on my system. unfortunately, this system is so old, i doubt it will meet the system requirements of anything newer than XP.

one might also, entirely reasonably, suggest upgrading the harddisk to something larger. memory is cheap, after all. it's a little difficult to justify upgrading the drive just to accommodate microsoft's attempts to fix their earlier mistakes, though. it's certainly not like i'm going to get any additional benefit from greater space on a drive i never make use of.

one could even go so far as to suggest upgrading all the things so that not only would i be able to move to the latest version of windows, i could have more space and a snappier system that is more amenable to being used day to day. but i already have a computer that's more amenable to being used, so really everything that was wrong with the idea of upgrading the drive is also wrong with this plan, in spades.

it's times like this that make one question things we normally take for granted, like why does it patching take so much space? is the fixed binary that much larger than the one with the error in it? no, that doesn't appear to be what's going on. it appears that windows keeps a bunch of stuff around so that you can uninstall the patch if you want to. does anyone ever actually do that? there may be a way to reclaim the space those uninstall files take up, but it's not obvious just by looking at the system, and right now simply letting the updates happen the way an ordinary user would is actually reducing the utility of the system.

thankfully the utility that's been lost wasn't really needed anymore. but what about next time? support for XP is ending, but it's not over yet, there are still more patches coming. i'm going to be facing the prospect of no longer getting patches anyway, so i might as well get used to it early - and since the system is little more than a network attached storage device that spends most of it's time powered off, i can't really see the harm.

in security, we normally think of applying patches as a no-brainer. it may present some logistical hurdles in the enterprise, but it still needs to get done. sometimes, though, there are cases where it just doesn't pay off. no practice is so universally beneficial that it should be mindlessly applied 100% of the time.

is the iphone really malware free?

friday morning mikko hypponen posted a tweet about the folks behind flexispy changing the look of their site, and i took the opportunity to pose a question to him about iphone malware. you see, flexispy is (or was) a piece of mobile malware that f-secure posted about about 6 years ago. not only that, but there's a version of the software for the iphone, so i found mikko's repeated statement that there was no malware for the iphone to be a little strange in light of the fact that both he and his company have been aware of software that seems to contradict that claim for quite some time.

the resulting discussion with both mikko and his colleague sean sullivan lead in 2 separate directions, so let's look at them in turn. first mikko responded with the following:

@imaguid No malware for iPhones. If you jailbreak your phone: all bets are off. Flexispy runs on jailbroken only.

now to me, this gets to one of the hearts of the matter. when people say there's no malware for the iphone, they're only talking about non-jailbroken phones. the pertinent difference between a normal iphone and a jailbroken iphone is that normal iphones can only install apps from the app store. the app store is a so-called walled garden where all the apps go through a screening process to keep out undesirable programs.

so what people really mean when they say no malware for the iphone is that there's no malware in the app store. this is an important distinction, because the iphone ecosystem (and by extension, the threat landscape) extends beyond the app store. when chris di bona attempted to downplay the threat malware played to android devices by pointing to google's efforts to keep their android marketplace clean, a number of folks were quick to point out that the android ecosystem extended beyond google's android marketplace, so it seems strange that people would forget the same line of reasoning applies to the iphone as well.

one other thing (well, the only other thing, really) that mikko said was:

@imaguid ...and to top it all: we couldn't do anything about iPhone malware anyway, as Apple won't allow Antivirus products to iPhone.

and you know what? why should they allow them when there's apparently "No malware for iPhones"? whether or not there is malware for the iphone, apple doesn't want people to think there is. there is this (rather old) idea that computers can be as easy to use as an appliance (like a toaster). this idea is actually very appealing. it promises computers that just work, computers that don't get malware, computers that are easy and safe and worry free. that promise is part of the secret sauce behind apple's marketing, but if they allowed AV products in then it would dispel the illusion of the appliance computer and apple's products would lose their lustre. it's very convenient, then, that AV vendors are willing to be complicit in apple's marketing by repeating the claim that there's "No malware for iPhones".

but such unqualified claims are, as mikko has revealed, not technically true. it's not that there's no malware for iphones, it's that there's no malware in the iphone app store.

but wait, is that really true? is there no malware in the app store at all? i'm not sure that's true when we've recently been made aware of apps in the app store that collect and send personal information to a remote server without the user's knowledge or consent. but it's about time i turned my attention towards the much more verbose and nuanced discussion that sean sullivan and i had on the subject. perhaps he can shed light on why these personal info stealing apps shouldn't be considered malware. while mikko didn't question the classification of flexispy as malware, sean informed me that f-secure no longer calls it malware.

@imaguid @mikko But they then added an installation interface, and we have since categorized it as riskware.

that's right - in spite of the fact that it is designed and marketed as a tool for spying on other people, it is not classified as spyware or malware because it was given an installation interface - meaning that the attacker has to have physical control of the phone for at least as long as it takes to install an app. now, on the desktop this might be a meaningful mitigating factor, but on mobile devices where physical access is so much easier to achieve? come on...

why exactly that stops it from being malware in general or spyware in particular in the context of mobile device security i still can't fathom, but sean offered up two things by way of explanation. one being a concern over being sued... by malware vendors. this rationale is something i heard from dr. solomon years and years ago, but i have to admit i had hoped that the industry had become less spineless in the interim. i guess that was too much to hope for. google may stand up to the government on behalf of it's users (perhaps not always, and perhaps it doesn't always succeed, but it has tried), but apparently anti-malware vendors only stand up for their users when there's zero risk they'll be challenged.

the other thing he offered was the following definition of spyware from google:

Software that self-installs on a computer, enabling information to be gathered covertly about a person's Internet use, passwords, etc.

apparently it's not enough that the software spies on you in order for it to be called spyware, it has to "self-install" as well. now i'm sure i must be missing something, because this definition seems to exclude anything where the victim is socially engineered into installing the software (it's hard to call it self-installing if the victim is the one installing it). it also seems to exclude anything that utilizes the particular trojan horse case where the software actually does perform the function it claims to, so the payload is additional functionality instead of strictly misrepresented functionality. a game that also steals passwords, a text editor that also sniffs network traffic, webcam software that just happens to send the video stream to a second undisclosed location in addition to the intended recipient - all of these are examples of software that ought to be called spyware but which the victim actually knowingly installs (because the undesirable functionality is unreported) and thus fails to meet the "self-install" criteria. this is precisely the type of situation users of the photo sharing iphone app called path faced.

now, sean also pointed me towards the anti-spyware coalition's risk model description document. i had hoped it would help me to learn more about this "self-install" concept that sean assured me was part of an industry agreed upon standard definition. things didn't turn out that way, since the term "self-install" doesn't appear in that document, but the topic of installation and distribution do figure prominently in the contexts of both risk factors and consent factors. unfortunately this document from 2007 appears once again to be geared to desktop computing rather than mobile computing. that's probably not too surprising considering it's 5 years old now, but it does highlight the age old problem of letting context into the classification process. mobile devices are easier to gain illicit physical access to, as well as being shared more freely (and more frequently) in social circumstances by their owners. the issue of consent at the point of install has far less significance as a risk mitigation for mobile devices. furthermore, the issue of consent at the point of install pretty clearly drops the ball in the case of trojans because it's not necessarily fully informed consent.

as the risk model description document demonstrates, somewhere along the line the industry gave up on basing it's classification system on functional definitions. sean insists that this is a "stricter process" but i think it's more correct to say that it utilizes more criteria than a functional definition system would. utilizing more criteria doesn't always lead to a stricter process because not all criteria are created equal and, at least in the case of the risk model description document, some of those criteria are used to create exceptions (which are generally not the hallmark of a strict process).

one of the last things sean wondered is how could the AV industry possibly use my (supposedly) broader definition(s) and not be accused of FUD. now, aside from the fact that the industry is already accused of FUD (and worse) pretty much regardless of what they do, i think it's important to spell out one of the key differences between a functional definition and the kind of definitions that sean sees in use. definitions that include contextual evaluation are judgements, they engender choice and leave room for agendas. a functional definition has no judgement, it is purely descriptive of the functional capabilities of what is being classified. you can no more be blamed for saying software that spies is spyware than you can for saying water is wet or the sky is blue. there's no silver bullet to make accusations go away, but if you take judgement out of the equation it should render those accusations baseless.

so why is all of this important? because it appears that we've somehow stumbled upon a way in which malware can be classified as "riskware" instead of malware. nobody hears about the riskware classification, nobody cares. they hear "No malware for iPhones" and they shut the rest out because that's all they needed to know (or at least according to traditional notions of malware that should have been all they needed to know). classifying malware as something other than malware seems to be what's enabling people to make the "No malware for iPhones" claim, like some kind of terminological shell game. "No malware for iPhones" makes people think the devices are safe and worry free, but there are risks, and not just for those who jailbreak."No malware for iPhones" is creating a false sense of security and with the revelations that have been made about apple's abject failure to lock down a particular type of personal information and the near ubiquitous exploitation of that failure by app developers, it seems like the stuff of snake-oil.

i tend to think that when people face risks they want to know about them rather than be told there's nothing to worry about, and i tend to think that when those risks come in the form of software that acts against the user's interests, informing the user is the AV industry's job. some people don't want that to happen, they want their own interests to take precedent. if the AV industry allows that to happen through inaction (or worse, facilitates it) then they don't deserve the reputation they have for protecting the user. the industry may not be able to put AV software on iphones yet, but they can certainly do a better job of raising awareness of the risks than going around telling people there's "No malware for iPhones". maybe when public awareness is raised apple will change their ways.

image from secmeme.com

the problem with the "like" trade

earlier today randy abrams posted an interesting take on facebook advertising and how misleading the word "like" can be (http://randy-abrams.blogspot.com/2011/12/facebook-misleading-advertising.html). this reminded me of a beef that i've apparently had going back at least as far as may of this year (judging by the timestamp on the screenshot i took).

specifically, randy said the following:

If I have to “like” a page to get the information I want, I don’t have a problem with that

well, with all due respect to randy, i do have a problem with it. randy makes some good points about the way people's pictures get used in facebook ads when they "like" things, but a point he neglected is that forcing users to "like" or otherwise post about something before they can see the content they've been lured with is a popular tactic in facebook scams.

now, i'm not trying to suggest that security companies making use of this marketing methodology are scam artists (though i am tempted to say that all marketing is in some way a scam) but they should be aware that by utilizing this sort of marketing they are effectively endorsing a marketing methodology (developed by facebook) that breeds victims. i don't expect facebook to care about such things, since such trickery is how they make their money, but i certainly expect security companies (especially ones with as strong a leaning towards empowering users as eset) to know better than to go along with facebook's questionable methods and do things like this:

"like"s are not something to be bought from users in exchange for free or otherwise tempting content. they are an endorsement and as such can't be legitimate until after the user has sampled the content. the idea of exploiting illegitimate user endorsements should be recognized as unethical and should be understood to have consequences. by using the sort of techniques that scam artists thrive on, one is basically training people to be victims. i expect better from security companies and i think you should too.

privacy in the age of forever

i've written before about what i think privacy is, though classifying it as an obscurity-based strategy for satisfying a basic need for safety was very high level and abstract. it could also be taken the wrong way, since people often think about safety as only applying to their physical person (i.e. physical safety). our physical bodies aren't the only thing we want to keep safe, of course. our families, our property, our reputations, our opportunities, etc. are all things we want to keep safe, all things we want to protect, and all things for which privacy can help offer some protection.

privacy is often described in terms of controlling information but on reading danah boyd's thoughts on privacy i realized it can and should be expressed a different way. controlling information is the means by which privacy is often accomplished, but it's not what privacy is actually about. while i don't agree with the narrow scope boyd used ('asserting control over social situations'), at it's root was a kernel of truth. while the means by which privacy is achieved may be the control of information, the point is the control of outcomes related to that information, whether they be social outcomes, business outcomes, educational outcomes, housing outcomes, health outcomes, political outcomes, legal outcomes, etc.

controlling outcomes is, of course, the point of any strategy. the thing about strategies, though, is that their appropriateness depends heavily on the situation, and what people largely don't realize is that there is a situation which is becoming increasingly ubiquitous under which many traditional privacy strategies don't work very well.

in the online world everything is recorded and stored for consumption at a different time or in a different place. it is essentially a persistent medium through which we can interact with each other. this is a significant point because for most of human history the real world has largely been an ephemeral medium for interaction. our behaviour, the strategies that we develop as we mature in the real world take great advantage of the ephemeral nature of our interactions with others. if you weren't present the day your best friend made a hurtful comment about you to others in your peer group then you missed out, that experience is gone, "you had to be there" as it were. this ephemeral property of the event, the fact that the information only exists in a very particular point in time and space, serves to restrict access to that information to only those who were present at the same point in time and space.

once we start interacting online that ephemeral property ceases to exist, so access to the information that we might have otherwise expected to be restricted due to it's ephemeral nature is no longer restricted in that way. we often don't realize that, however, because we take that 'ephemeral-ness' for granted. it's not easy adapting to a situation where that no longer applies.

for example, imagine for a moment that every word you speak goes into a speech bubble above your head, like in the comic books, except unlike the comics the speech bubble doesn't go away, it stays with you and allows people to read what you said 5 minutes ago or even 5 hours ago. every swear word, every uncharitable thought uttered under your breath in the heat of the moment, everything. can you imagine how you'd adapt to that sort of situation? you'd probably censor yourself a lot more than you currently do - since your utterances have become persistent the natural adaptation that would allow you to continue to control the outcomes associated with what you say is to say far less.

at first blush that might not seem unbearably bad, but let's take things a step farther because that example really only dealt with your words. this time (this is inspired by danah boyd's post, by the way), imagine you are stuck in a very large room and surrounded by everyone you ever have and ever will meet. imagine trying to live your life in this room. how do you play with your toddler in front of your business partner or a potential client? how do you woo your future wife in front of your children or your parents? how do you hang out with your high school friends in front of your future employers? how do you project an image of cool professionalism to people who saw you fall face first in a mud puddle? again, in such a situation, surrounded by people from disparate contexts of your life, the natural adaptation is to reduce the amount of information that you reveal about yourself, but think about those questions; there are certain outcomes that can't reasonably happen without revealing sensitive things about yourself.

these examples may seem absurd, but this is what it means to interact in a persistent medium. anyone, anywhere, at any time can (in theory) see the footprints you've left in that medium. your interactions in a persistent medium transcend time and space, allowing people to effectively 'TiVo' your life (or at least the portion of it that's been recorded).

obviously this represents an unacceptable state of affairs for online interaction. there's very little utility in it if it requires such profound self-censorship. that's the reason that technological privacy controls and privacy settings were invented - to help replace the access control that was lost when the information became recorded. unfortunately the technological controls don't operate the same way that ephemerality does, so trying to achieve a simliar outcome with them is complicated and often not intuitive.

sean sullivan (at least i assume it was that sean) made a post on the f-secure blog that highlighted a talk given by clay shirky where he said (as quoted by sean) that "managing privacy isn't natural". technically what shirky said was that managing privacy settings isn't natural. we manage privacy every day in every interaction we make with others, but managing privacy settings by definition can't be natural because the settings themselves are artificial. this has implications for the kind of privacy one can achieve though managing such settings - it is itself an artificial, man made analog to natural privacy, and prone not only to being incomplete in comparison to it's natural counterpart but also to breaking down as all man made things do.

but as untrustworthy as that sounds, it will have to be good enough, because we can't turn back the hands of time or halt progress. we can't even opt out of the persistent medium. oh, we might get away with staying out of the online world ourselves, but persistence is intruding into the real world more and more. public photography, for example, is turning the public sphere (which used to represent an ephemeral medium) into a much more persistent medium than it used to be. this can be a good thing when it helps to expose things like police brutality, but it poses a not insignificant problem for us as a society.

paul ducklin raised some concerns about this very problem last year on the sophos blog. at the time i didn't think his concept of public privacy made much sense, but when examined through the lens of a traditionally ephemeral medium of interaction being changed into a persistent one without people noticing or appreciating the consequences for their existing privacy strategies, it starts to be clear (to me) that this is a problem that deserves some consideration. i wouldn't consider it an invasion of privacy, per se, but perhaps it would qualify as a subversion of privacy, since it changes the environment to one where the strategies people were using to control outcomes no longer work properly, and it does so without making it clear that that had happened.

are we ready for the implications of living in a world where our actions live on beyond the moment? i don't really know. certainly we can manage our privacy settings online, and maybe we can obscure our identifying features offline (though that may interact poorly with some of our cultural norms) so that public photography becomes less of an issue. i just wonder if explaining to the next generation what it was like before everything became persistent will be the last time we ever get to use the phrase "you had to be there".

thoughts on metasploit's impact

i listened to the network security podcast #257 this afternoon, specifically because i wanted to hear what martin mckeay, josh corman, and hd moore had to say about metasploit and what josh corman calls HD Moore's Law. there were a lot of mentions of PCI and being 'this tall to ride the internet', but the comment that really caught my ear (i was listening to it rather than reading it after all) was that metasploit allows people to test their security against the attacks that are readily available.

and then a voice in the back of my head said "yeah, but metasploit is what makes those attacks readily available". it's essentially equivalent to saying that the readily available attacks allow people to test their security against the readily available attacks - i believe the way the internet identifies such tautologies these days is by saying "obvious statement is obvious".

one of the interesting things josh corman brought to the conversation was a breakdown of adversary classes (i encourage you to read his post that i linked to above, not only for that breakdown but also a visualization of their relative success rates against a scale of defender strengths) and it occurs to me that, in the absence of metasploit, these so-called readily available attacks that are in the hands of the casual attacker wouldn't generally be in the hands of the casual attacker (and thus wouldn't be the readily available attacks) but rather in the hands of adversaries of a higher calibre.

one thing that isn't really mentioned but seems fairly obvious is that the higher up you go on the scale of adversary classes, the smaller the population will be (the more skills one has the rarer one becomes) and consequently the smaller the aggregate pool of practical targets will be (since there's a limit to what any one given person can pull off in a given period of time, the manpower available to an attacker is a finite resource). that means that in the absence of metasploit, these attacks would be directly impacting fewer systems - probably more important systems, but fewer systems in total.

now before i go any further, lets address an assumption i've made. i think it's an obvious one. you've probably had it on the tip of your tongue for at least the past two paragraphs. the assumption is that in the absence of metasploit nothing else would pop up to take it's place. for my purposes, that's actually not so much an assumption as it is an ideal starting point or degenerate case from which to build a more complex model.

so let's say that another group of well-meaning researchers decided to pick up the gauntlet. i see no intrinsic difference between that hypothetical case and the actual case we have with metasploit right now. that makes it really not that interesting an alternative, because it's not really alternative in any meaningful sense. the more interesting alternative lies in the argument that if the good guys didn't do it, if they were all too principled (for lack of a better word) to follow that path, then the bad guys certainly would.

so in that case let's say a group of ne'er do wells decided to produce a similar tool. would it be the same? would it have the same properties and present the same problems? i would argue that it wouldn't - that the incentives in the underground community are different enough that what would be produced either would not be free (and therefore not available to all casual adversaries) or it would not be as capable as metasploit would have been (perhaps because the best exploits would get held back in order to give the developers a competitive or strategic advantage over the attackers they're helping for free). the motive of doing it for the benefit of everyone (that drives the excellence found in the free edition of metasploit) simply isn't compatible with financially motivated cybercrime. greed and selflessness don't mix, so a criminal-driven equivalent to metasploit wouldn't lower the bar as far as metasploit does.

so what am i trying to say? what am i really getting at with all of this? the TL;DR version is that the metasploit folks are too nice to people, including the bad guys. the notion that metasploit represents the attacks that are readily available suggests to me that they lower the bar too much. no one seems to disagree that metasploit is a tool that is used by script kiddies (among others) and so i'm left to wonder very seriously whether there's an actual legitimate use case for metasploit that involves such a completely unskilled user. leave no user behind? i think under the circumstances an exception deserves to be made.

marketing bullshit isn't just from marketing departments

so apparently there's a conference going on right now called hacker halted. i heard mention of it a few days ago but paid little attention because frankly there are just too many security conferences to keep track of. what piqued my interest yesterday, however, was a retelling of something george kurtz is supposed to have said in one of the keynotes at the conference - specifically, he's quoted as saying the following (from @InfosecurityMag's tweet)

industry has to move beyond signatures and customers need to demand this from the vendors. We need to change and adapt

now i have to admit i had no idea who george kurtz was. fact of the matter is i have no idea who most people in the security field are (so if you're wondering why i don't follow you back on twitter or add you to a circle on google+, that's a strong contender for the reason why). i thought he was just some crank talking about things he didn't really know much about (more common than you might think, unfortunately) because the AV industry hasn't been relying exclusively on signatures for quite a long time.

imagine my surprise to discover george kurtz is actually the chief technology officer at mcafee, of all places. would such a highly titled representative of an AV company really say such a bizarre thing? well, if symantec's CEO can claim the virus problem is solved, then i guess so, but it still begs the question "what was he thinking?"

thankfully rik ferguson managed to tease a little something extra out of george on twitter

George Kurtz woke up in 2008 today "industry has to move beyond signatures". Helloooo? McFly?

@rik_ferguson maybe you missed the part about the hardware assisted security. Opps.. forgot you don't really have that at Trend.

and there we have it; the quote that people are fawning over (or scratching their heads over) was actually marketing bullshit. oh sure, on the the surface it looks like an AV big wig eating crow and admitting that his company isn't doing a good enough job and needs to improve; just the kind of frank confession we're all waiting for the AV industry to make. but with this added wrinkle we see that's not it at all. george's company supposedly already has improved and it's everybody else who still has the problem. mcafee has this licked, mcafee is the solution, buy mcafee.

no, he didn't actually say 'mcafee is the solution, buy mcafee' (to the best of my knowledge), but that is the reality distortion he's setting up - and distorting reality that way is the hallmark of marketing. all that remains is to publicly declare that deepsafe (their hardware assist technology that they announced over a month ago) is how you "move beyond signatures" and the marketing message will be complete with reality suitably distorted to mcafee's benefit and everyone else's detriment.

now you might be thinking to yourself that this can't be true, that such a highly placed and well respected security expert would never stoop to such base gamesmanship. the fact is that not only do most public faces of the industry practice marketing regularly in the process of representing their respective companies, but most high profile speakers rise above the rest not strictly by merit but by effectively selling themselves and building their personal brands - and if they have to stretch the truth or fuzz the facts or distort reality to make their message more palatable to the masses and give themselves more cache and influence, then so be it.

and the unfortunate consequence of this is that, due to the fact that the rest of us rely on such speakers to inform us, much of what the majority of us know about the the subject matter in question is actually somewhat wrong in subtle (or not so subtle) ways. reality distortion interferes with the formation of accurate mental models and that in turn interferes with people's ability to deal with the parts of the real world those models are supposed to represent. one of the things i've tried to impress on people in the past is that they need to stop listening to marketing, but i realize now that i don't have an easy method for them to recognize it in the first place. at least not without developing much more thorough knowledge than they currently have, and to do so without relying on apparent authorities on the subject in question is no easy task.

no, marketing bullshit isn't restricted to the glossy pages of a magazine or the cover of a box or an ad on tv. it's not just the product of marketing departments. it's woven into the very fabric of what we think we know, and it's hurting us.

facebook's ticker: a ticking privacy timebomb?

there's a lot of pixels and bits being dedicated to the major changes that are underway at facebook, but most of the attention seems to be focused on the timeline feature. i tend to think the ticker feature deserves a lot more attention and, frankly, concern.

first off, it seems clear that facebook wants to be the destination for an ever increasing number of activities - not just farmville or mafia wars, but consuming print, audio, and video media, and even purchasing goods too. fine, facebook wants to be the web portal to end all web portals - the next AOL or compuserve - it's fine to have aspirations like that; although actually being AOL or compuserve doesn't seem to have worked out that great for AOL or compuserve in the end.

but with that breadth possible activities in mind, the idea that facebook will now be sharing everything you do automatically seemed really rather stupid to me at first. maybe there is too much friction inhibiting sharing right now, maybe clicking a button isn't easy enough, but truly "frictionless" sharing that happens without any action taken on the user's part takes the intent out of sharing. sharing loses all meaning that way. it no longer tells you the sharer thought this article was insightful or that video was funny, it doesn't give any hint what so ever as to whether the sharer thought something was worthwhile, it just collects everything in one big activity profile. indeed, was the person performing those activities really the sharer in that situation, or is the sharer facebook themselves?

at first you might think that the resulting poor signal/noise ratio would render facebook as irrelevant as myspace and it's blinking, glittery profile pages has become. the folks at facebook seem to have realized this, though. they don't want people's main feeds to get filled with all that noise. they recognize that from a personal interaction standpoint, this data is too voluminous and unimportant. that's why they've relegated the data to a new place - the ticker.

the question you should be asking yourself right now, however, is this: if this data isn't actually useful to users when they're connecting with their friends, why is facebook interested in automatically sharing it? who is interested in that data? the answer is simple - advertisers. a large profile of everything you read, watched, listened to, and did online is for all intents and purposes your web history. in this case it will be your web history as seen through the eyes of facebook. we in the security community get upset about browser vulnerabilities leaking our browser history, or tracking cookies being used to track where we've been; the data collected for ticker is not going to be inherently different than the data acquired through those other means. furthermore, it's too voluminous and granular to be useful to anything other than an automated process that looks for certain types of patterns and trends. the kind of process you'd use for the automated targeting of ads - targeting based on your activities, your behaviour.

the ruse of "frictionless sharing" appears to be a trojan horse (not the malware variety one might traditionally think of, though) for introducing behavioural profiling for the purposes of targeted advertisements. social spyware at it's best.

but even if that's not the case, even if that data really is meant for a user's friends to see and use, there is a profound implication buried in the automated sharing of everything. you can't control your public image if the choice of what you share about yourself is taken away from you. for all the hand wringing recently about the damage that real name policies do (eliminating your ability to control the personal information that your identity represents), the elimination of your ability to control your public image means the elimination of the persona - something that has been part of the social experience of humans since the dawn of mankind if not longer.

our true selves, the nature that we keep hidden behind the masks that we each present the world, is something that we innately keep private. i simply cannot believe that our social norms are headed in the direction of completely removing those social masks. giving up that private information in exchange for access to a service is a privacy bargain that we have never faced before.

so, if you thought the ways facebook could violate our privacy couldn't get much worse, you were dead wrong.

tavis ormandy's sophail presentation

at the black hat security conference this year tavis ormandy presented his research into the way an anti-virus product, namely sophos' product, operates in order to shine a light on something seems like it would be an important subject to consider when judging the efficacy of a product. the paper associated with the presentation can be found here.

tavis was not particularly kind in his evaluation of the code (which he apparently performed by reverse engineering the product). sophos' response is very measured and diplomatic, which is pretty much the perfect way (from a PR perspective) to respond to the kind of criticism being leveled at them. as usual, however, i don't have to be diplomatic.

tavis' paper betrays a conceit that i suspect is more common in those who break things than it is in those who make things. developers, upon dealing with someone else's code, inevitably learn an important lesson: the code tells you what the software does, but it doesn't tell you why it does it that way. tavis thinks he knows all he needs to know, but he only had the code to go by. so when it comes to why certain things were done the way they were, the only thing he could reasonably do is make educated guesses. in some cases those guesses may well have been quite good, but in others they were not.

i first realized this was going to be the case on the second page of the paper where he describes how weak the encryption used on the signatures was, often an XOR with an 8 bit key. if you were to guess that such encryption was to protect the signatures from an attacker, as tavis seems to have, then you'd be dead wrong. the primary purpose encrypting signatures serves is to prevent other anti-virus products from raising an alarm on the signature database (something that used to happen in the very early days).

on page 3 it's mentioned that the heavy use of CRC32 in the signatures means it's easy to maliciously create false alarms by creating files that have the same CRC32 values that a particular signature is looking for and in the same places. now i ask you, the reader, if someone is maliciously planting files on your network that are designed to raise an alarm, is that alarm really false? it may be a false identification, but there really is something malicious going on that an administrator needs to investigate.

also on page 3 he criticizes the quality of the signatures by stating they appear to ignore the context of the programs they come from, that they're for irrelevant, trivial, or even dead code. perhaps tavis expanded on this in his live presentation, but the paper doesn't make clear whether or not he actually looked at the malware the samples were supposed to be for. if he didn't, then the criticism about ignoring context would be particularly ironic. let's assume then that he did. how many malware samples did he examine? if only a handful then there's a not insignificant chance that he was dealing with bad examples that aren't really representative of the overall signature quality. did he ensure that his samples were actually malware? did he ensure that his samples were being identified by the right signatures? his previous criticism (on the same page!) about false identifications should highlight the fact that hey may have been looking at the wrong code when judging the quality of the signatures. but more importantly than that, there isn't a 1-to-1 relationship between signatures and samples. one signature may be intended to detect many (tens, hundreds, even thousands of) related samples - and however pointless tavis may think those sections of the malware code are, they may represent the optimal commonality between all those samples.

around about page 8 or so, tavis makes a point of highlighting the fact that the emulation the product does in order to let malware reveal it's unencrypted/unpacked form only goes for about 500 cycles. this highlights a failure to understand one of the core problems in malware detection: the halting problem. for any other criteria the code might look for in deciding it's seen enough, there's no guarantee that criteria will ever be encountered on a particular input program. there has to be a hardcoded cut-off point or the process runs the risk of never stopping - and that would severely impact the usability of the AV software. likewise if the hardcoded cut-off point isn't reached soon enough it also impacts the usability of the AV software.

there may yet be other examples of poor guesswork that i didn't see. my own knowledge of why certain design choices might be made is limited as i've never actually built an anti-virus product. i have considered it, of course, since i am a maker of things. perhaps tavis ormandy would benefit from more experience making things rather than breaking them. perhaps this was an unorthodox expression of the oft' repeated concept that the skills needed to attack are not the same as the skills needed to defend.

careful who you let write the history books

over the course of the previous two weeks, kevin mcaleavey has been publishing a series of blog posts on the infosecisland site (parts one, two, three, four, five, and six) about the history of the anti-virus industry. rob lewis thought this might be a subject that would interest me and he was right. unfortunately, rather than finding it mostly informative, i found with each passing part an increasing desire to post a serious critique. i'll take them one part at a time.

part one

to start with i think we need to pay attention to how the author presents himself. each part refers to him as a long time industry insider, but doesn't go into anything more verifiable or specific than that. with such vague credentials (and those are meant as credentials - there's no reason to put them there except to try to convince the reader that the author is an authority on the subject he's writing about) it really feels like he's saying "trust me, i'm a security expert". now i've never heard of him but that alone doesn't say that much, the anti-virus industry employs hundreds if not thousands of people and i'm really only familiar with a comparative handful of them. in part three we get to find out more specifics, but for the time being let's just say that such nebulous credentials makes me very suspicious.

to be fair i should point out my own credentials, so that i'm not being a hypocrite. unlike kevin, i am not now, nor have i ever been an industry insider. i have never been employed by any company in the anti-virus industry, i have never received financial remuneration for anything i've said or done involving the anti-virus field, and frankly i've only ever met a handful of people who were part of the industry. that being said, what i am (in terms relevant to this discussion) is a long time observer of the anti-virus industry. i've always been on the outside looking in, but from about the age of 15 onwards i basically grew up interacting with security hobbyists, security professionals, security software engineers, security researchers, and even some of the big names that kevin mentions in part two.

in theory, being an outsider seems like it should mean i have a more superficial view of the anti-virus industry.  we shall see.

the first part of kevin's series focuses mostly on where we are today so a lot of the things he mentions should sound familiar to people following the security news. one of the things he mentions is the rustock botnet. he presents it as a single piece of malware with a 5 year half-life. this is a bit misleading for a couple of reasons, the first being that rustock is actually a family of malware - there have been many versions since 2006, in part because the anti-virus industry keeps interfering with the utility of existing versions by detecting them. additionally, the term "half life" has a very specific meaning which doesn't really apply that well to a botnet that has for all intents and purposes been killed now that microsoft controls the command and control server.

subsequently he made the following quote:

"TDL4" however has publicly caused the security industry to transition into full panic mode and literally throw in the towel

this may seem pedantic, but in order to literally throw in the towel, there has to be an actual physical towel, and someone has to throw it. an argument could be made, i suppose, for saying that they figuratively threw in the towel, or metaphorically threw in the towel. maybe even virtually threw in the towel - but if he insists that they literally threw in the towel then i have five words - pics or it didn't happen.

now there was some early misinterpretation of the use of the word "indestructible" that got posted in less knowledgeable media circles, specifically that the malware was indestructible rather than the observation that malware authors were trying to create an indestructible or bulletproof network of compromised computers, but a knowledgeable industry insider should have been able to see through that. furthermore, from my perspective the only panic i saw was the panicky feeding frenzy in the media over a statement which, like so many more purposeful scams, was simply too spectacular to be true.

i got the distinct impression upon reading part one that he tends to take mainstream media as gospel when it suggests that all is lost in the fight against malware. that seems strange to me. why is an industry insider putting so much credence in what the mainstream media says? he acknowledges that the industry has called this interpretation wrong, and that they're trying to correct that misinterpretation but he seems to suggest that the "corrections" are a product of public relations rather than a genuine attempt to correct factually erroneous statements that spread fear, uncertainty, and doubt.


another statement i'd like to draw attention to is the following:

To see this public admission that 1980's technology has utterly failed is nothing short of breathtaking.   

admission by whom? where? what are the details? none are given and we must take him on his word that such an admission actually took place. or perhaps he thinks the misinterpretations spread by mainstream media represent that admission. could it be that he's unfamiliar with the degree to which they botch things up on a regular basis? it really makes me question his credibility if he placing his preference on the words of reporters over the words of researchers.

part two


part two is where he actually starts talking about history. he starts right at the beginning but there's a problem. he mistakenly thinks the brain virus 'destroyed' many hard disks. brain came out at a time when hard disks were a rarity. moreover, brain specifically avoided infecting hard disks. the link kevin himself provided says this so i can only assume that he's not actually reading the sources he's providing to the reader.

he also seems to mistakenly think brain required a reinstall to recover from. this is, of course, false. there have always been less drastic ways of restoring boot sectors. the main problem was information about doing so wasn't as easy to come by back then as it is now. still, thinking there wasn't a way to do it is essentially a form of ignorance that you wouldn't expect to find in a long time industry insider.

yet another point on the brain virus; he seems to think the backlash from it forced the developers who made it out of business. i guess he never saw this video by f-secure's mikko hypponen, where mikko found the developers of the virus still working at exactly the same address they were at 25 years ago when they originally wrote the virus.

brain isn't the only piece of malware whose details he gets wrong, though. he mistakenly thinks popureb requires a windows reinstall to remove, much like brain. in reality what's required is to restore the MBR with the recovery console. this seems to be another example where kevin has taken mainstream media at their word instead of digging deeper and getting actual inside information, the way you'd expect an insider to do.

he also seems to think that stoned was the first virus to go memory resident and infect any disk that was inserted in the drive. stoned was a boot sector infector, however. all boot sector infectors infect (more or less) every disk inserted into the drive, it's kinda how they spread, and since it wasn't the first of that sort of virus i can't imagine how he got the impression it was the first one to go memory resident.

more generally he seems to think the majority of viruses in the 90's were jokes and pranks and programs designed to delete files. my recollection is that most actually gave no outward indication of infection whatsoever. virus writers quickly decided they liked the notoriety that came with one of their viruses spreading far and wide, and the best way to help that to happen was to make sure it didn't make itself known by messing up people's computers. the ones that stuck out in people's memories were oftentimes jokes or pranks or had destructive payloads, however.

it's not just malware he seems to get wrong, however. he appears to be under the impression that VIRUS-L was a private echomail conference available to SysOps (system operators) of BBSes that carried FidoNet. VIRUS-L was actually an internet mailing list which was gated into usenet in the form of the newsgroup comp.virus. i have no doubt it was further gated into FidoNet - i know alt.comp.virus was as my first encounter with it was through a usenet-to-FidoNet gateway. i have a feeling i encountered comp.virus the same way (without ever being a SysOp). that said, it's possible kevin could have been thinking of something else; maybe VIRUS or VIRUS_INFO (or even VIRUS_NFO) which were in fact echomail conferences on FidoNet (the first two of which have me as their most recent moderator). they also aren't private, however; i really can't seem to figure out where that part of his recollection might have come from.

another curious thing i noticed is that he seems to think eugene kaspersky is the only member of the old guard of virus hunters still in the field after john mcafee, alan solomon, and peter norton (?) left. he also mentioned frisk software international but sort of as an afterthought, and somehow failed to mention frisk the person. frisk the person (and the company) are still out there, still working. they may not be attracting attention but they're still there. as such, kaspersky isn't the last so kevin's depiction of the industry as having been lobotomized seems all the more inaccurate. what's more, however, is that kevin only seems to be acknowledging a handful of the icons in the anti-virus industry. there were and are a lot more people from the old days out there. a great example would be aryeh goretsky, who was from the sounds of it like john mcafee's right hand man, and who currently is with eset. then there's the venerable vesselin bontchev, once a well respected virus expert at university of hamburg and now a well respected virus expert at FSI. then there's jimmy kuo of symantec and then mcafee and now microsoft. there are many great minds from the early days that are still with us today, so this focus on just a handful of icons and the suggestion that since most of those are gone that the industry has been lobotomized, seems like a decidedly superficial view.

part three

the third part in kevin's series was about the demise of the anti-virus industry (it's not dead, it's just sleeping). it's also where we finally find out about his actual credentials. he was part of privacy software corporation, the company behind BOClean; what was apparently originally a cleanup tool for the back orifice remote access trojan, but was later expanded to cover more malware. apparently this company was bought by comodo in 2007, but from the sounds of things it doesn't sound like kevin stayed on with comodo for all that long, and even if he was still with them today 4 years isn't exactly "long term".

he presents himself as a long term industry insider in a discussion about anti-virus vendors, but his actual first hand inside experience with the kinds of companies he talks about and criticizes in this series of posts only went on for 2 1/4 years according to his linkedin profile. that seems rather underwhelming. oh sure, before that he spent a long time in a different part of the anti-malware industry, but he spends very little time actually talking about the part of the industry where most of his actual experience is from - except to extoll the virtues of the techniques used by BOClean, of course. in any event, it's clear by this point why he was so vague about his credentials in earlier parts.

back to the demise of the anti-virus industry, however. kevin focuses on the point in which trojans started to take off as the death knell of the industry. it was, after all, the point at which his company was forced to start dealing with malware. he seems to think that the early failures to handle trojans reflected inability on the industry's part. just to be clear, when trojans began to take off the industry did hesitate, and i don't mean for a second or a minute or an hour or a day or week or a month or even a year. the anti-virus industry hesitated to redefine itself. it took a lot of doing to overcome the philosophical inertia that kept them out non-viral malware detection. trojans were not viruses, remote access 'tools' arguably had legitimate uses, and the industry was gun-shy with regards to litigation. i hope kevin can appreciate that last point as it was his revered dr solomon who explained that one to me. apparently they couldn't even add generic detection for MtE based polymorphic viruses using the existence of the MtE algorithm as an indicator because some brainiac went and put the algorithm in a 'legitimate' code obfuscation tool. the industry did eventually overcome their philosophical qualms about dealing with non-viral malware but it took the escalation of the trojan problem to make people (both inside and outside the industry) realize that the industry would be justified in going after this new kind of threat that was previously outside of their purview.

a great deal of kevin's characterization of the failure of the industry seems to focus on what his company handled better. the reader is left to take his word for it that his company did a better job. he's clearly not an impartial 3rd party, his perceptions should be taken with a grain of salt. he talks about a number of techniques used by the anti-virus industry and what their failings are - a number of which are almost certainly exaggerated. i've seen my share of alternative anti-malware approaches whose proponents go on ad nauseum about how their approach is the superior one (zvi netiv stands out as a remarkable example of this). better is always subjective, there's always good and bad points.

he describes BOClean's approach of only looking for the malware in memory, rather than trying to find it on disk like traditional anti-virus products do, as superior. there are benefits, of course. packers and cryptors have no effect on detection because that transformation is undone at runtime. however, there are also drawbacks. once the malware is in memory it is active. it's possible for active malware to interfere with security software in any number of ways. it could use stealth, it could shut down the security software (which i gather was a problem for BOClean), or it could even use the security software's own filesystem enumerating behaviour to find new host programs to infect (if you're dealing with a file infecting virus). once the malware is active the security software has lost an important tactical advantage. imagine you're in a street fight - do you wait for your opponent to strike first or do you try to strike before they're even in a position to defend themselves? and remember, i'm talking about a street fight here, not some fair fight with referees and judges. you do not wait for the malware to go active in memory if you can avoid it. the code that gets control first wins, and once the malware is active in memory, it's gained control. it's only by kevin's good fortune (or BOClean's low profile) that malware creators didn't try to stomp out or otherwise interfere with BOClean. the AV industry has already faced that, going back all the way to brain (which had stealth).

some of his exaggerations devolve into more factual errors. for example he calls win32/ska a simple file infector and criticises the industry for taking months to handle it. the fact is that win32/ska's infection technique was nothing like the traditional file infection technique kevin laid out elsewhere. win32/ska was not some appending file infector, it didn't simply insert itself into the winsock DLL, it carried a modified copy of the winsock DLL with it and replaced the original with the modified version. as such, recovery of the original winsock DLL was not comparable to recovering from a traditional file infector. it may have taken months to build the capabilities to recover from this type of infection into their general purpose tools, but that in part was because there were special purpose tools available to mitigate the problem and lower the priority of getting it into their general purpose products. there also happened to be manual instructions for removing win32/ska (i know because i have given those instructions to people) which also mitigated the problem and thus lowered the priority.

he also points out that even now systems are still getting compromised with back orifice 12 years later and characterizes that as an example of the anti-malware industry's failure. the fact is that his BOClean is just as much a failure in that as the rest of the anti-malware industry is. that is if you can really call it a failure. stopping that trojan from ever getting used again, making it become extinct, that's just not something anyone can actually do. and it doesn't really have that much to do with whether the malware can be detected or removed by software tools, but more with the heterogeneity of the computer population and the mind-share of the malware in question amongst those who would use it. old viruses never die, and apparently old trojans don't either.

he places the blame for why all windows malware works at all on microsoft. unfortunately it's not that simple. any general purpose computer is capable of supporting malware, no matter what the operating system. in this way malware can be said to be a 'feature' of general purpose computing. no matter how tightly you try to control things, there will always be the potential for software to maliciously do something you don't want it to do.


kevin seems to think that AV industry has for the past 30 years (which is longer than the industry has actually existed) simply been coming up with signatures and not looking for patterns that could be useful for future variants. the fact that we have the concept of malware families at all invalidates this line of reasoning. it wouldn't be possible to classify new samples as belonging to an existing family without looking for such patterns. this line of reasoning also ignores heuristic alerts that say "possibly modified variant of X". it also ignores the practice of consolidating many specific signatures into a few generic signatures.

he also calls automated analysis 'cheating' and characterizes it as simply creating an MD5 or SHA1 hash. this seems to ignore the fact that you can't logically identify that a sample is a variant of another malware family by simply creating a hash. it also clearly ignores the concept of automated classification, whereby a sample is compared with many other samples in order to determine which ones it's most similar to and thus which family it belongs to. one also has to wonder how exactly vendors are supposed to deal with 100,000 new samples a day without some kind of automation. even if you had a way to detect most of those new samples ahead of time with generic signatures, you still need to test and make sure each of those new samples is actually malware and is actually detected.

rather unsurprisingly at this point, he describes heuristics as bad because they emulate the malware while trying to catch it in the act of doing something bad. this is only (somewhat) true of dynamic heuristics, not static heuristics. it's also hypocritical coming from someone championing the idea of letting the malware become active in memory before trying to do anything about it.

he also referred to heuristics as creating "massive" false positive problems. in reality false positives are relatively rare. a single false positive can, of course, cause problems for many people if it's a system file, but those are rare even amongst regular false positives. those really high profile failures are something that has only happened a handful of times.

part four

the fourth part of kevin's series focuses on operating systems, mostly windows, but covering mac os x and linux too. i actually agree with a lot of what kevin has to say in this part (which makes me wonder if my knowledge of OS security might be a little too shallow), but there are a few things that are worth pointing out.

i tend not to agree with his suggestion that the concept of file associations based on file extensions are a bad thing and should be replaced by some kind of intelligent parsing. for one thing i think the parsing idea is logically infeasible. intelligent parsing would require windows to know about every file format, even the one i just invented yesterday, which it obviously can't. he also envisioned that the parser could generate a warning for the user to indicate what sort of action windows was about to take, but the warning could just as easily been done with file associations. the warning is based on the outcome and has little to do with how the outcome is decided upon (be it parsing or association).

on the matter of unix, kevin appears to be of the opinion that pure unix was secure. this would seem to ignore the fact that the original academic treatment of computer viruses (where the term actually got coined) had a virus spreading on a professionally administered unix system without the admin's assistance. how secure is that?

he also seems to believe that linux used to be secure in the beginning, but seems to forget or not care that rootkits worked on linux way back close to it's beginning. he admits that there was malicious software but contends that it got removed from distros quickly after being introduced. this ignores the fact that once end users start using such an OS, malware doesn't need to be bundled into the distro. if a user can run it, they will, and linux didn't and doesn't prevent running malware

part five

the fifth and penultimate part of the series deals the concept of defense in depth, or as kevin prefers layered security. he spends an inordinate amount of time talking about firewalls and how awful they are. he sort of presented defense in depth as a caricature, focusing only on the layers that gained widespread adoption and suggesting that anything else was outside of the regular user's price range. frankly i don't think integrity checking was ever priced that way, nor behaviour blocking, nor any number of other techniques that he conveniently ignores.

what's more, he criticizes each layer for being insufficient. it's as if he doesn't understand the purpose of having multiple layers. each one has flaws and weaknesses, sure, all security measures do, but in aggregate those weaknesses are diminished. they're never completely eliminated, of course, because there's no such thing as perfect security, but it's certainly something that we can approach. one might argue that one can approach that by re-engineering one particular layer instead of having many, but some of those weaknesses are inherent rather than being design or implementation flaws. such inherent weaknesses can only be braced by other additional, complementary layers.

part six

the final part of keven mcaleavey's series was meant to present solutions to the problems mentioned in the previous 5 parts. when i read the final part in the series all the pieces finally clicked into place. all the confusion i previously had was gone, all the WTF moments finally made sense. i finally knew what he was on about and what the series' true purpose was. kevin's got a product to sell and the series was an extraordinarily long sales pitch.

it followed a familiar pattern too, now that i think about it. first he dished out FUD about his competitors (and since he's now a secure systems provider his competitors include both the anti-malware software vendors and the operating system vendors), and then at the end hype up his own product and make it look like the blatantly obvious choice to avoid the horrible, horrible problems with everything else. he even threw in a smattering of snake oil phrases like "absolute security and protection" for good measure.

the product and/or service in question (KNOS) appears to my untrained self to be similar to some sort of freeBSD-based LiveCD composed entirely out of carefully audited modules, and with the provision that you can request custom configurations from to suit your needs. the idea appears to be that the code that is allowed to run is carefully controlled and limited by them (rather than being something the user can add code to him/herself) and that exploitable vulnerabilities have supposedly been eliminated. this is supposed to keep the users safe from both malware and from them themselves.

unfortunately, kevin seems to have fallen prey to the engineer's conceit - the (often mistaken) belief that a particular problem can solved through carefully engineered technology alone. KNOS does not offer absolute protection, and to say it does offers users a false sense of security. it may well stop all the malware that kevin can imagine, but (to paraphrase something that's often said in cryptographic circles) it's easy to come up with a security system so advanced that you yourself can't figure out a way around it - what's hard is figuring out one that other people can't figure out a way around either.

obviously i don't know enough of the details of KNOS to suggest specific scenarios where it's security can fail, but i do know enough about computation in general to see what kevin (and others who aim to ensure only good/safe code is allowed to run) has missed. what many people don't realize, what society's conventional thinking about computers fails to hint at, is that data is code. the distinction we draw between the two is little more than a mental construct that simplifies the task of building systems. it doesn't represent how computation actually works, and it isn't necessarily adhered to by the people who break systems.

unless and until someone can come up with a way to control which data gets processed as scrupulously as they control which code gets executed, data will remain an open window through which systems with locked down code can be attacked. and since determining the safety of data will ultimately require the data to be processed in some way, we arrive at a catch-22.

i fully expect that KNOS probably has some impressive security capabilities, but absolute security is a fantasy, and the more traditional security layers that kevin derides have managed to keep me essentially malware free (except for an externally non-addressable RAT installation on a sacrificial secondary system) for over two decades. beware security historians who are trying to sell you something - chances are they'll rewrite history to suit their sales objective.