The Malware Industrial Complex 32
holy_calamity writes "MIT Technology Review reports that efforts by U.S. government agencies and defense contractors to develop malware to attack enemies is driving a black market in zero-day vulnerabilities. Experts warn that could make the internet less secure for everyone, since malicious code is typically left behind on targeted systems and often shows up on untargeted ones, providing opportunities for reverse engineering. '"On the one hand the government is freaking out about cyber-security, and on the other the U.S. is participating in a global market in vulnerabilities and pushing up the prices," says Soghoian, who says he has spoken with people involved in the trade and that prices range from the thousands to the hundreds of thousands. Even civilian law-enforcement agencies pay for zero-days, Soghoian says, in order to sneak spy software onto suspects’ computers or mobile phones.'"
Seen first hand (Score:4, Interesting)
Posting A/C and being more vague than I would like... sigh... A certain company I used to work for based their whole product on the ability to install what was essentially a rootkit. My role was to pull data off the network. I didn't have too much problem with that, since if you're porn surfing on company or government networks, or leaking info, you sort of get what you deserve. Say what you will about Bradley Manning, but he had to know what he was getting into. OTOH, they wanted to push me around in various ways I didn't like, and the thought of persuing a career there where my work would be less about legitimate protection of the network, and more about ubiquitous surveillance... it just left a bad taste in my mouth. I thought I might end up working on the rootkit, and the whole idea stuck in my craw, not only because of the increasing fascist tone of the US approach; but because of the inherently fucked up approach to security. I mean, if we can do this to their computers, they can do it to ours.... the whole thing, just more and more sour. My career has yet to recover, because I was pretty much groomed to be a military-industrial coder at that point, and wanted nothing to do with it. It's pretty much impossible to transfer over to the happy-bouncy-fun world of phone apps in your 40s, and all of that stuff is morphing into surveillance anyway. One of these days I might just unplug all the computers and chuck 'em.
It's like a high speed arms race (Score:5, Interesting)
On one hand, your enemies can use those same vulnerabilities against you.
But on the other hand, since you know about them first, you can get your systems protected from those vulnerabilities. But if the fix is propagated too quickly, then you've just immunized your enemy.
A logical way to fix the vulnerability is to have more sophisticated detection at the border gateways into your private network. Like an intrusion detection and prevention system at the router. That way you don't actually release the fix, at least not too soon, to the whole world. The knowledge of the zero day exploit is only in the code to attach your enemy and in your border defenses. But not in the OSes, not in the browsers and whatever other general purpose software is being exploited.
If your friends, say the power grid people, need protection, you can provide it to them, without disclosing what the vulnerabilities are, by providing them with the same border defenses you use. Eventually, whenever you deem necessary, you can disclose the vulnerabilities to the vendors and let them fix it directly in the affected software.
A side effect of all this is to generally improve the security situation for everyone, eventually. Assuming there are not an infinite number of vulnerabilities, and that after the low hanging fruit is picked, the vulnerabilities get fewer and more difficult to exploit, then everyone's system, including your enemy's has become pretty secure.
If the security situation becomes bad enough, it might forcibly change the way we approach writing software. Just like when type safety was introduced into languages decades ago, our very programming languages may make it harder to have security flaws. Preventing programming errors must have some overlap with preventing security flaws. If your language doesn't allow direct access to pointers, had garbage collection (to prevent double delete, memory leaks, reference after delete), doesn't allow array index out of bounds (preventing lots of problems), you have excluded some types of vulnerabilities that had been common in the past. The language cannot fix all security problems, just some of the most basic ones.
Some work could be done in the language to help the libraries prevent certain classes of attacks. Introduce a new kind of type checking where you have, say, Html-Safe strings and must go through some function to convert Unsafe String into an Html-Safe strings. They are not assignment compatible. Similarly you could have another type of Sql-Safe strings. If the language mechanism were extensible, then you (or your library designer) could introduce other types like JavaScript-Safe strings, or XML-Safe strings, or Postscript-Safe strings, just to make up a few examples. In short you would have to go through well defined functions to convert from an unsafe string. You couldn't pass an Unsafe String to the format string parameter of, say, printf() so you would eliminate accidental format string attacks, just as you would prevent rendering an Unsafe string on an ASP/JSP/PHP or whatever you call it page that has embedded scripts. Widgets in your active pages could not accept unsafe strings from the "controller" objects. The language, api's and libraries would work together to prevent accidental "assignment" of the wrong kind of strings, just as decades ago they prevented assigning integers to strings.