Friday, June 24, 2016

Vulnerabilities Resist Catagorization

Policy is a lot about categories of things. Recently I was reading a paper which categorized exploits in a way that rang weirdly to me, since I spend all my time thinking about exploits.

The title of this paper could be "Regulating this stuff is going to be mindbogglingly hard" but click here to read the full thing:

Here's what I want to say about that: You cannot sort exploits into any distinct categories without oodles of work and a lot of hand-waving that makes it useless for regulation. I'm not saying this to pick on this particular paper or its categories, which derive from one of Mikko's more morose ruminations on the subject. It's a common problem and a real issue with designing intelligent policy in this space.

Let's talk briefly about this one vulnerability to explain how hard this can be. The Spooler exploit was two phased:

  1. You could use a bug in the remote procedure call (RPC) endpoint to write arbitrary files to arbitrary places on the disk as "Admin". This is useful, but is not remote code execution (you cannot overwrite files).
  2. Writing MOF files into certain very specific places will allow you to execute code (this is not a bug or vulnerability, but a very rarely known feature). It's interesting to note that the original Metasploit exploit for this issue used AT Files for this part of the exploit, as they didn't know about the MOF technique, whereas CANVAS and Stuxnet both used MOF files.

Also, the spooler bug was not an "0day" in the sense that people most often use it. While unknown in the wider community (or by Microsoft) it was published in a Russian magazine years before.  

Imagine trying to ban 0day exploits that "allow for remote code execution". Would the Spooler vulnerability fall into that regulation? Perhaps only when combined with the knowledge of MOF files or the ATSVC technique? What about when you realize that the vulnerability was already in a Russian magazine? What about how the code it allows you to execute is VBScript, and not native code? And how it only effects Windows systems that share printers or have a specific configuration?

There's a thousand different categorizations you could apply to exploits, is what I'm saying, and none of them are universally available or even technically correct in a majority of cases. Right now the policy world tries to ignore this with legalistic jargon, but the physics of the problem are not going to change to make it any easier, unfortunately.

No comments:

Post a Comment