> The recent bagle_remover.nasl script sets a somewhat dangerous > precedent, IMHO, of crossing the line from vulnerability detection > to remediation.
if you replace 'dangerous' with 'complex', I'd agree. The risk is, imo, in having folks start to expect this sort of behavior in the future. Having the virus remove itself may save you a few hundred infections. In either event, Nessus will flag it as a security hole and the honus is still on the Administrator to manually verify that the virus is gone and clean up the reg keys (which bagle remover doesn't do). >Not to mention that you are trusting the bagle > remover script to do its own removal cleanly. >There are a number > of reasons why this is bad, not the least of which is that I > personally would not trust a virus to remove itself cleanly to > begin with. It is by definition, after all, untrusted code. Ah, OK. This is true for 'unknown virii'. That is, I wouldn't trust an *unknown* virus to remove itself. If the virus has been decompiled and it's behavior is known, then I don't see a problem with using built-in mechanisms to perform triage on the virus...The bagle_remover.nasl is, after all, an attempt to stop the bleeding until the admin can manually arrest the machine. > > I would suggest that this script be modified (if possible) into > a detection only script and leave the corrective action out as > a separate activity. incidentally, the presence of bagle is also checked for in smb_virii.nasl. So, there are actually two checks (one requiring registry access) John Lampe jwlampe -at- nessus.org http://f00dikator.aceryder.com/ _______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
