[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C2D4BF3B836E7D1678B39E81@Macintosh-2.local>
Date: Sun, 11 Oct 2009 20:24:36 -0500
From: Paul Schmehl <pschmehl_lists@...rr.com>
To: James Matthews <nytrokiss@...il.com>,
"Thor (Hammer of God)" <thor@...merofgod.com>
Cc: full-disclosure@...ts.grok.org.uk, Valdis.Kletnieks@...edu,
Jonathan Leffler <jleffler@...ibm.com>
Subject: Re: When is it valid to claim that
a vulnerability leads to a remote attack?
--On October 11, 2009 7:18:33 PM -0500 James Matthews
<nytrokiss@...il.com> wrote:
> If you classify a remote bug (anything that can be exploited remotely)
> then you are classifying all bugs (you can use a privilege escalation
> exploit remotely) I agree with Thor, anything that exploits a remote
> service (HTTP,FTP Etc..) without any user interaction.
>
My understanding of the classical meaning of "remote exploit" is that the
machine can be exploited without the attacker needing to have an account
on the box. A local exploit is one that requires that the attacker first
obtain access to the box. For example, you can exploit ls on a Linux box
to elevate your privileges, if you can first get on the box through ssh or
some other method.
I have never seen remote exploit definitions require the limitation of no
user action.
When discussing taxonomy and the usefulness of vulnerability definitions
in real world scenarios, it's much more useful to know that something can
be exploited without the attacker having access to the box. Certainly a
higher priority is placed on resolving those issues than ones where the
attacker first has to obtain access.
Paul Schmehl, If it isn't already
obvious, my opinions are my own
and not those of my employer.
******************************************
WARNING: Check the headers before replying
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists