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-next>] [day] [month] [year] [list]

Message-ID: <4425F7F0.3020109@linuxbox.org>
Date: Sun, 26 Mar 2006 04:09:52 +0200
From: Gadi Evron <ge@...uxbox.org>
To: djweber@...m.mit.edu
Cc: bugtraq@...urityfocus.com
Subject: Re: On classifying attacks

Daniel Weber wrote:
> Crispin Cowan wrote:
> 
>>I participated in that Lincoln Labs study, and my recollection is
>>that the remote/local distinction was already popular on bugtraq at
>>the time.
>
> 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.
> 
> Simplicity is key.  (Unlike this posting, which I did not have time 
> to make shorter and simpler.)

What made my life a little confusing of late was not Trojan horse 
attacks, as I got used to the idea of treating them with a different 
terminology all-together. Once on the system, it is compromised and how 
the attack happens is irrelevant but *can* be quantified. How it got on 
the system is the question here.
I.e., remote connection exploiting a service, etc.

The issue that bothers me is how we treat browser or generally client 
side vulnerabilities.

I often see advisories on bugtraq such as this:
Remote exploit while using a browser to gain local access
After reading, I find out it's an SQL injection.

Another example is, if a user has to browse to a remote site to get 
exploited, it is true the attack code was on a remote site, but the 
processing, the exception and the exploitation happened locally.

The difference with other client attacks triggered from remote location 
is the attacker. If he/she connects to you and tries to exploit, the 
service is running and then runs into say, an exception. With a browser 
you go to a remote site, download code, run it locally and get exploited.

I am not sure what these should be called, but an SQL injection is not a 
remote vulnerability as we term it, despite some similarities.

Many of us still argue on what a worm vs. Trojan vs. virus, etc. are. 
Let's not get to the stage where we have that with vulnerabilities.

	Gadi.