Lost in Reception

In addition to the false-positive risks in email that interest me generally and the real-world analogies that I noted a couple of months back, it appears that some behaviour by legitimate software developers is indistinguishable from that of malware developers.

Since its inception, the closed-source software industry has benefited from – even depended upon – the fact that object code is much harder to work with than source code, so keeping source code secret and delivering object code to customers has been an effective way to help keep a developer’s secrets secret. Increasingly, tools for reverse-engineering are diminishing this advantage so those developers whose businesses are particularly dependent upon keeping their implementation details secret are turning to code-obfuscation tools to make analysis of their delivered code even more difficult. Naturally, malware authors are using the same tools to the same end.

Igor Muttik opens a recent post by suggesting that anti-malware technology is digging an elephant trap for us all because of the above; he moves on to suggest that legitimate software authors might consider (a) not obfuscating their code in the first place or (b) signing their code if they do obfuscate it.

This closely parallels the forces at work in dealing with email abuse:

• It is unwise to behave like a bad guy (conceal click-counters under links in email, send frequently to people who haven’t asked you to; or, in the physical world, wear a balaclava into a bank, …).
• An important mitigation of the false positive risk is to increase the ability of assessors to identify good actors which, when errors in both directions are common, is not simply the inverse of the ability to identify bad actors.

Part of the solution being pursued by anti-malware vendors (who might now prefer to be termed security vendors) is a transition to whitelisting, much as is beginning to happen on a large scale for email.

Perhaps this is obvious. We depend upon our ability to recognise trustworthy professionals (doctors, accountants, engineers) through the licensing procedures of their professional bodies, upon police officers’ ability to recognise trustworthy participants in high-risk activities (notably the driving of powered vehicles on public streets) through vehicle registration and driver licensing procedures and upon our own ability to recognise trustworthy borrowers through credit-rating agencies. Frequently the means of dealing with negligent or malicious behaviour in public, at least when life and limb are not at stake, is to provide the means for anyone to recognise individuals who are trustworthy. Perhaps applying such ideas to email and to software loading/execution is merely going back to the future.

Further thoughts:

• The term “elephant trap” is an interesting one. I’ve never given any thought to the trapping of elephants but I imagine that a large, disguised pit placed where elephants might be expected, or caused, to stampede would suffice. Whether the resulting trapped elephants, with multiple broken bones, would be of value as beasts of burden is a speculation left open to the reader. Wikipedia has an entirely different take on this: apparently it’s the name of a situation in chess.
• Legitimate developers using obfuscation – or even those merely depending upon the difficulty of working with object code -, malware developers and DRM advocates all share a similar mindset: that it is reasonable to turn a computer against its owner contrary to that owner’s desires (albeit with their consent, for suitably convoluted uses of the term “consent“), a situation described in common law as conversion when consent is absent. When your customers are your opponents, life gets difficult. It bothers me that my living has tended to derive from sources that [believe that they] [might] have this dependency.

(Relevant disclosure: as usual, I am writing on my own behalf but there is a considerable overlap between my view and the views and initiatives of BoxSentry.)