DISQUS

Byron Sonne · 3 years ago

"Worst use of strategic vs. tactical ever."

Why do you say that? I thought it was pretty good ;) Think about it from a militaristic perspective.

Dr. Strangelove · 3 years ago

I agree, the initial analogy makes some sense; however, the way he uses offense/defense methodology to justify it seems kind of silly. The way I see it, you'll have to test for vulnerabilities long after the better majority of systems exhibiting the bug have been patched.

It seems the breakdown in the analogy is that vulnerability checks are both a strategic AND tactical approach to the vulnerability problem at large, while exploits are merely a tactical approach.

It pays to know in the long term what systems are still vulnerable, so there's always a use for the check-based scanner. As the number of affected machines, for a given vulnerability, decreases so does the value of the exploit.

I agree with Dave's observation that checks and actual exploits are better viewed as alternative ways of approaching the same problem, as opposed to trying to classify one approach as a short term solution, and one as a long term solution is convoluting the facts, and more so than necessary.

If you need to choose between the two, vulnerability checks (that actually work) are an inherently better approach to internal asset assurance inventory than working exploits are; and strictly because of the fact that they retain their value pre-exploit, pre-patch, post-exploit, post-patch. The same can not be said for a working exploit. Not to mention the fact that the majority of bugs you are going to be able to exploit remotely, usually do not involve a memory layout that allows you to successfully exploit a vulnerability without corrupting some stack/heap data.

Also, relying on successful exploitation, or service failure, to ascertain exposure to a vulnerability is a momumental fuck up of epic proportions.

-ds

ivan · 3 years ago

dear mr. -ds , regarding your last comment:
"Also, relying on successful exploitation, or service failure, to ascertain exposure to a vulnerability is a momumental fuck up of epic proportions."

That is an interesting thought, I remember reading about it more that 10 years ago when Farmer and Venema published a paper titled "Improving the security of your site by BREAKING into it", someone should tell them they've been wrong for a decade.
I guess nothing has changed in the infosec industry since 1996 then and I should start looking for a job in the firewall or av industry.
As for the value of exploits pre,post and forever after patch deployment (or ex-ante and ex-post as my friendly lawyer likes to say) all I can say is that patches not always patch, sometimes they are not even properly deployed, sometimes they are properly installed but the box remains vulnerable due to lack of proper reboot, sometimes they are removed, overriden by others or the bugs they patch are not necessarily the same ones they claim to patch so it may be useful to have exploits laying around just to check that you are right (it sounds reasonable, but maybe its just me being stubborn and wanting to check things by myself instead of trusting the patch issuer or great patch deployment system as I've been told to do)

I did not understand the following part of your post, would you explain what you meant?

"Not to mention the fact that the majority of bugs you are going to be able to exploit remotely, usually do not involve a memory layout that allows you to successfully exploit a vulnerability without corrupting some stack/heap data."