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.
> 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.
[ reply ]