On Wed, 10 Feb 1999, Randy Taylor wrote: > One of the hard lessons I learned long ago when writing vulnerability > testing code is that exercising exploit methods can do more harm than > good. A crash or a system lockup may be the result, even though the code > was written to avoid such a thing. In other words, stuff can and often does > happen. :-} Unfortunately I do not doubt this. But it is the only way to make a conclusive check. I think that there should be at least two "testing-modes" available, one that can be used on production systems without having to be afraid of loss of service, and one "real attack" mode. When a real attacker tries to exploit the vulnerabilities and it results in a crash, system lockup or in worst case a succesful exploit attempt one probably wishes a "real attack" test would have been made in the first place though.. > In the end, no commercial vulnerability testing tool can or should > substitute for good old-fashioned human analysis of the post-test report. This can not be emphasized enough.. > While I agree an attacker will most certainly attempt a full-blown > exploit, the attacker has no liability in the corporate sense. A commercial > testing tool like ISS or CyberCop does have such a liability. ISS and NAI > have relatively deep pockets, and must exercise due diligence and care in > the methods used by their products to test for vulnerabilities. No one would > buy their products if they crashed or locked up systems on a regular basis. > Crackers have shallow pockets (or none at all ;), and no such concerns for > diligence or care. Thats's what disclaimers are for.. ;-) Well, as said before, at least two "testingmodes" should be available. I realize this a real pain to implement, but they are _really_ useful and certainly should be of very high priority. > Best regards, > > Randy / Joel Eriksson
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:34:11 PDT