David M Chess wrote:
> But many of us *love* to argue about taxonomies and word meanings (it's
> cheaper than booze anyway). *8)
>
> To my mind, if the attacker needs to be logged into an account on the
> machine being attacked then the vulnerability is local; if the attacker
> just has to be able to push bits to a port then it's remote. If the
> attacker has to trick a legitimate user into doing something (including
> going to a particular remote site) then it's a Trojan horse. Not hard and
> fast boundaries (what if the attacker has to first push some bits to a
> port and then fool a user into clicking on a link in some email and then
> log into a local account?), but to first order...
>
> Calling an SQL injection a "Trojan horse vulnerability" sounds a little
> odd, I admit. But until something better comes along?
>
> DC
I spoke about this problem extensively with a few friends since this
post came up, and a few suggestions came up:
1. A user-assisted remote attack.
2. A client-side remote attack.
I.e., we can add "user assisted" as a class like "local" and "remote",
or add types (think ICMP here).
I.e., remote or local, then, client-side, user-assisted, etc.
This is just to put these out there again and somehow come up with a
short generic list of just a few terms to help us along. If we create a
full taxonomy again everyone will ignore it.
Here's a quick initial attempt:
Vulnerability Class
1. Local
The code runs locally and initiated locally for a purpose such
as privileges escalation and/or code execution.
2. Remote
The code runs locally but initiated remotely, for any purpose
from access gaining to a combined attack with privilege
escalation or code execution.
Vulnerability Types [Optional]
These are more of understanding rather than descriptions.
1. Client-side
The vulnerability is on a client (such as Internet explorer) but
by no action initiated by the user by social engineering or
other means, i.e., automatically exploited.
2. User-assisted
User had to go to a web-site or click on an attachment as
instructed by the attacker.
Questions remain:
- How does one treat an SQL injection?
It is client-side, but doesn't affect the Browser directly but
rather the database. This is remote but not an exploitation/etc.
issue.
Can we treat these as configuration issues? These are still
input validation mishandling matters. Should it be called remote
but then set to type: Poisoning?
- I.e. do we classify vulnerabilities by severity? Determining said
severity is a difficult matter which is why remote/local works so well.
- Do we also try and treat general terminology so that we all use the
same language? As in, privileges escalation, directory traversal, etc.
and should these, like the possible "poisoning" be Types, which would
suggest they would still be "remote". Should remote be saved for "code
executions"?
> But many of us *love* to argue about taxonomies and word meanings (it's
> cheaper than booze anyway). *8)
>
> To my mind, if the attacker needs to be logged into an account on the
> machine being attacked then the vulnerability is local; if the attacker
> just has to be able to push bits to a port then it's remote. If the
> attacker has to trick a legitimate user into doing something (including
> going to a particular remote site) then it's a Trojan horse. Not hard and
> fast boundaries (what if the attacker has to first push some bits to a
> port and then fool a user into clicking on a link in some email and then
> log into a local account?), but to first order...
>
> Calling an SQL injection a "Trojan horse vulnerability" sounds a little
> odd, I admit. But until something better comes along?
>
> DC
I spoke about this problem extensively with a few friends since this
post came up, and a few suggestions came up:
1. A user-assisted remote attack.
2. A client-side remote attack.
I.e., we can add "user assisted" as a class like "local" and "remote",
or add types (think ICMP here).
I.e., remote or local, then, client-side, user-assisted, etc.
This is just to put these out there again and somehow come up with a
short generic list of just a few terms to help us along. If we create a
full taxonomy again everyone will ignore it.
Here's a quick initial attempt:
Vulnerability Class
1. Local
The code runs locally and initiated locally for a purpose such
as privileges escalation and/or code execution.
2. Remote
The code runs locally but initiated remotely, for any purpose
from access gaining to a combined attack with privilege
escalation or code execution.
Vulnerability Types [Optional]
These are more of understanding rather than descriptions.
1. Client-side
The vulnerability is on a client (such as Internet explorer) but
by no action initiated by the user by social engineering or
other means, i.e., automatically exploited.
2. User-assisted
User had to go to a web-site or click on an attachment as
instructed by the attacker.
Questions remain:
- How does one treat an SQL injection?
It is client-side, but doesn't affect the Browser directly but
rather the database. This is remote but not an exploitation/etc.
issue.
Can we treat these as configuration issues? These are still
input validation mishandling matters. Should it be called remote
but then set to type: Poisoning?
- I.e. do we classify vulnerabilities by severity? Determining said
severity is a difficult matter which is why remote/local works so well.
- Do we also try and treat general terminology so that we all use the
same language? As in, privileges escalation, directory traversal, etc.
and should these, like the possible "poisoning" be Types, which would
suggest they would still be "remote". Should remote be saved for "code
executions"?
Gadi.
[ reply ]