full-disclosure - Re: When is it valid to claim that a vulnerability leads to a remote attack?

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]

Date: Sun, 11 Oct 2009 21:42:07 -0700
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: Paul Schmehl <pschmehl_lists@...rr.com>, James Matthews
	<nytrokiss@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>,
	"Valdis.Kletnieks@...edu" <Valdis.Kletnieks@...edu>,
	Jonathan Leffler <jleffler@...ibm.com>
Subject: Re: When is it valid to claim that
	a	vulnerability leads to a remote attack?

I think the classification system as a whole is ultimately based on agenda.  Vendors (I presume) don't want things to sound as bad as they may be.  Researchers want things to sound as bad as they CAN be.  And the rest of the people would like a means by which to measure "urgency" to patch as it relates to cost/benefit, risk/threat, and potential consequences of inaction.  

So I think it ultimately comes down to a sliding scale of what the person responsible for incident response is comfortable with.  To me, I draw the line of a "remote" exploit to "no user or system interaction required" as I've previously stated.  You have to make SOME sort of qualification, or else calculated responses become unmanageable. 

Analysis beyond that (to me) enters you into a model of diminishing returns.  By way of example:  If you can send an email exploit to an Outlook client that can execute by a preview only, is that remote?  I would say no, as a user would have to preview it.  If one could exploit the same vulnerability just by it arriving into one's Outlook inbox without preview would it THEN be remote?  Again, I would say no, as Outlook would have to be running.  And, of course, one would have to be running Outlook in the first place.  

As a group, I don't think we need to define what "remote" is.  That's up to the response team.  What you need to do is decide on what you do when YOU classify something as remote, and then take action according to a predefined plan.

That is really the advice I have for the OP.  Don't look to what other people consider remote; decide for yourself, and plan a course of action accordingly.

t

> -----Original Message-----
> From: Paul Schmehl [mailto:pschmehl_lists@...rr.com]
> Sent: Sunday, October 11, 2009 6:25 PM
> To: James Matthews; Thor (Hammer of God)
> Cc: full-disclosure@...ts.grok.org.uk; Valdis.Kletnieks@...edu;
> Jonathan Leffler
> Subject: Re: [Full-disclosure] 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/