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.