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-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

Powered by Openwall GNU/*/Linux Powered by OpenVZ