Sunday, December 10, 2006

Negative vulnerabilities?

As part of the recent discussion having to do with agents introducing new vulnerabilities to a system, I've been thinking. Everyone agrees that adding software means adding vulnerabilities. Even if you're one of the best at writing bug-free software like Knuth or DJB, you still make the occasional mistake. (Even if DJB hates to admit it.)

Richard Bejtlich mentions it again while commenting on the agent discussion.
Worse, as is the case any time you add code to a platform, you are adding vulnerabilities.
Of course, I understand fully what people are saying when they say this, and I'm not trying to disagree. But that got me thinking.

Now, you can't have a negative number of vulnerabilities in your own code. At best, the theoretical minimum is 0. But could you, by adding code, remove someone else's vulnerabilities? I think it might be possible.

First off, there's the obvious case of a patch. You added something, and are now (hopefully) down one vulnerability, right? Well, not exactly. Modern patches work by replacing an entire chunk of code with one just like it, (hopefully) minus the vulnerability. It will, for example, replace an entire DLL. So that's not more code, that's different code. And sure, it might introduce more vulnerabilities too, but I'm trying to make a point here, work with me.

So fair or not, I just removed the vendor from being able to go negative on vulnerabilities. At least, not within the same software package. Nothing that says Microsoft couldn't add something outside of Word to remove Word vulnerabilities, though.

How about third-party patches? Well, depending on how they work, they might qualify for what I'm thinking. If there is something that sticks around all the time, and is somehow removing a vulnerability from another piece of software on that system (and adds none of its own, of course), then maybe it just achieved negative vulnerability.

Now, it's unlikely that a program of any size is not going to have its own vulnerabilities, so it had better fix a large number of someone else's. This is what I think the HIPS category is trying to do. If you look at Blink or Determina, they dig around in the guts of someone else's software, and do things that try to remove vulnerabilities. Or specifically, make them nonexploitable, downgrading them from vulnerabilities to just bugs. For purposes of this discussion, lets call the process exiting instead of running shellcode "no longer vulnerable."

Briefly, a sidebar: I'm quite annoyed by the current use of the term "HIPS". If you happen to be a Windows Secrets paid subscriber, you may have seen my article about that. Briefly, there is a bunch of stuff calling itself HIPS, including traditional stuff like AV and file integrity checkers (read: Tripwire.) Don't do that. Otherwise, you don't leave me a good name for things like Blink, Determina, W^X, DEP, and those categories of protection. Naming suggestions welcome.

So lets assume these things work, at least partially. If so, and they remove a substantial number of vulnerabilities (more than they add), then you have added software and removed vulnerabilities. Discuss.

(For those wondering if I have an ulterior motive on this one; not really. BigFix doesn't do this kind of thing. We might someday parter with a vendor that does, or add management of such products to our agent, but we don't muck about it the binaries of other software. I'm just interested in exploring the idea of adding software to remove vulnerabilities.)

No comments: