Re: [-SPAM-] Re: When is it valid to claim that a vulnerability leads to a remote attack?

[Thierry Zoller <Thierry () Zoller lu>]

Hi James,

Well, that  would explain why client side exploits are so fruity these
days. Probably  nobody  invests  into  protection  against  them , as the
risk assessment team tells them it is a local issue only ? Pun intended ;)

A  PDF/DOC exploit should be classified as remotely exploitable or else your
assessment suffers from lack of reality - sorry.

We  have  the following denominations in this thread, which
all mean different things, doesn't really help us here :
* "a remote bug"
* "a remote attack"
* "remotely exploitable"

"A remote attack"
= An action

"Remotely   exploitable"
= possibility that vulnerability is exploited  remotely

"A  remote  bug"=
a bug that is remotely triggerable (??) doesn't even imply it is exploitable.

I  only  perceive  one of these denominations to be worth being used in
risk assessment -that being "remotely exploitable"


JM> If you classify a remote bug (anything that can be exploited remotely) then
JM> you are classifying all bugs (you can use a privilege escalation exploit
JM> remotely)
Yes,  you actually  should  consider  you  can  use  these  types  of attacks
remotely,   but   "normally"   not   without   a  "first  degree  remote
vulnerability" (add that to the list of denominations).

JM> I agree with Thor, anything that exploits a remote service
JM> (HTTP,FTP Etc..) without any user interaction.

JM> On Sun, Oct 11, 2009 at 12:54 AM, Thor (Hammer of God) <thor () hammerofgod com
> > wrote:

> > > I  think we can agree that yes, it is remotely exploitable and as such
> > > should be categorized as "remote" in Risk/Impactt scoring systems ?
> > >
> > > Does anybody disagree ? I'd be interested to hear your point of view.
> >
> > Hey Thierry - I hope all is well...
> >
> > I'm happy to include "user assisted remote exploitation" as a "remote"
> > vulnerability in academic conversations, but I don't categorize it as
> > "remote" when assessing overall risk to a particular threat in production
> > environments.  Like everyone else, my TMs include impact and skill required
> > to exploit a particular vulnerability; but they also include "likelihood of
> > exploitation."   While that may sound like a wildcard metric, I quantify it
> > by applying the internal controls in place that may mitigate a particular
> > attack.  In "my" networks (networks I control, design, or consult for) most
> > users couldn't execute [common] exploits even if they wanted to.  I won't
> > bore you with the controls I deploy as I'm confident you are well aware of
> > the options one has, but the fact they exist at all place "user assisted
> > remote exploits" in a different category for me when assessing risk.  When
> > the propensity for a vulnerability to be exploited lies in a particular
> > user's response to any given
> >  trigger, as opposed to any authoritative in-place controls to mitigate
> > exposure, then a model's relevant response options are greatly diminished
> > (IMO).
> >
> > As such, I choose to categorize "remote" exploits as those that may be
> > executed against a given host that is autonomously running a [vulnerable]
> > service that can be connected to by some (any) other network client, device,
> > or service for the purposes of ascertaining overall risk.
> >
> > t
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/






-- 
http://blog.zoller.lu
Thierry Zoller


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/