not local.. not remote..
Posted by jericho
Several of us working on VDBs have debated over the years how best to handle vulnerabilities that aren’t necessarily remote or local. Issues like image or archive handling vulnerabilities, where the program processing a malformed file is prone to an overflow, traversal or denial of service. While one may argue they are ‘remote’ in the sense that if I e-mail you the file, the attack is definitely remote in a sense. But, if the malformed file is loaded via a floppy disk, the attack certainly isn’t ‘local’ or ‘requires physical’ access necessarily. So we need something that covers the grey area between vectors. A while back Steven Christey at CVE began using “context-dependent attacker” to describe such vulnerabilities. OSVDB tried to come up with another term for this but after some time, we couldn’t. So, from here on out, you will start noticing the use of “context-dependent attacker” in our vulnerability descriptions more frequently, and eventually when the classification scheme is overhauled it will appear there too.
Great, it’s good to see some consensus arising, specifically on such a persistently mis-categorized vulnerability type.
Out of interest, what is wrong with ‘client-side’ as a definition?
actually, we use “context-dependent” for issues that could be remote or local depending on how they are used. This frequently appears in libraries, which could be used in local or remote apps, or in API functions, whose arguments might be locally or remotely controlled.
We use “user-assisted” to try to get at what singe calls “client-side”, but even that term has limitations because we use it to imply when some amount of special user interaction is required to deliver the payload; we then modify this with remote/local depending on the typical expected channel of attack.