[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <OF210AB6C7.AAC001F1-ON85257140.00413F63-85257140.00492711@us.ibm.com>
Date: Wed, 29 Mar 2006 08:19:04 -0500
From: David M Chess <chess@...ibm.com>
To: bugtraq@...urityfocus.com
Subject: Re: On classifying attacks
> 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.
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
Powered by blists - more mailing lists