Vulnerability Classification Terminology
Posted by jericho
Local or remote, seems so simple when classifying a vulnerability. The last few years have really thrown this simple distinction for a loop. Think of a vulnerability that occurs when processing a file, such as a browser rendering a JPG or GIF, or a program like Adobe Reader processing a PDF file. On one hand, you could argue that a browser has to remotely load an image or a user must e-mail a PDF to be opened. On the other hand, what happens when the malformed file is given to you on a floppy disk? What if you are using MSIE to locally browse files on the hard disk? It’s not that local or remote are wrong, just not descriptive enough.
This debate has popped up on mail lists in the past year, and has been discussed at every VDB I guarantee you. After a couple years of discussing it internally at OSVDB, we haven’t been able to come up with a better classification scheme. Why? Everything we come up with is just as non-descript or overly complex. We can’t seem to find a good middle ground to cover such distinctions.
Recently, Steven Christey of CVE has come up with a middle ground and begun using it in some entries. For attacks that require external help to somehow deliver hostile material to a victim, he has begun using “external user-complicit attackers” and it seems to be a good fit.
Examples: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2471 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2501
Steve Tornio (one of the OSVDB manglers) also made a good point regarding classifying these, while still using the local vs remote designation:
“I classify almost all file vulnerabilities as local. Whether it is delivered by floppy disk or the network, or created locally on the machine, a malformed file is the vector for the exploit, and there is nothing about a file that makes it a network resource. Sure, it could be delivered via email or http, but classifying anything that could conceivably arrive over the network as a remote flaw devalues the remote/local classification, especially since the vulnerable application still needs to be launched and open the file from disk after it arrives.
The only exception I see is the growing collection of graphics file overflows, simply because the primary viewer of graphics on most computers is a web browser, and the primary vector for exploitation is the web.”
From: Daniel Weber To: bugtraq@securityfocus.com Date: Thu, 28 Jul 2005 15:26:40 -0400 Subject: Re: On classifying attacks
[..]
One of the mental models involved in those 1998 classifications of attacks was a “presence” of an attacker – is the attacker outside your network, on your network, or on your machine as a non-privileged user? This model doesn’t necessarily fit in well with some of today’s most common attacks, as was mentioned when this thread started.
I’ve seen a lot of classification schemes proposed on Bugtraq in the intervening years, some of them quite good. (Search the archives for “taxonomy” or “classification”.) But unless they are -very- simple to use, they won’t be taken up by the community. If you can come up with a single word that imputes the concept of “malicious data that I can easily get onto the victim’s machine and in front of the victim’s eyes but requires him to run it,” that would be a great step forward.
From: Duncan Simpson To: bugtraq@securityfocus.com Date: Sun, 24 Jul 2005 05:31:21 +0100 Subject: Re: On classifying attacks
Nobody has brought this up, so perhaps I should. The problem most clasiffication schemes discussed are hitting is that security holes are transitive: remote arbitary code execution+local root exploit=remote root exploit.
If the exploit code is running on your box then any exploits it peforms are probably local, even if the attack code is launched by a remote exploit. A description of a beast as composition of seperate remote and local exploits would allow a simple remote/local distinction to apply (where “local” means requiring the code to executed on the attacked box).
[..]