bugtraq - Re: On classifying attacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 30 Mar 2006 22:11:34 +0200
From: Gadi Evron <ge@...uxbox.org>
To: David M Chess <chess@...ibm.com>
Cc: bugtraq@...urityfocus.com
Subject: Re: On classifying attacks


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"?

	Gadi.