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) <t...@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/
