> >> 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
But, from a remote perspective, the virus IS unknown. We don't actually know what is running on the port.
> 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.
Actually, there are other risks as well. We all have seen viruses that have version B,C,D etc. So picture Bagel.B comes along, and it's "cleanup" action is to remove somewhat more than it should. Now, anyone running a not 100% up to date version of Nessus will end up performing some serious damage (and that assumes that the Nessus scripts are corrected quickly to prevent the propagation of damaging vulnerability scans).
Not that this is impossible in other circumstances (the machine, after all, HAS been compromised, and any protocol could be subverted). But it's just SO easy to see the virus author going ahead and 'enhancing' the removal function with unexpected consequences to anyone using Nessus (e.g. enhanced to remove the registry entry, but botched code corrupts the registry).
I think Renaud's original email, referenced by Jason, says best what I think ought to be the policy goal of Nessus - identify, and leave correction outside the scope of Nessus.
Thomas
_______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
