On Wed, 21 Jan 2004, Thomas Reinke wrote: > John Lampe wrote: > > > > >> 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
OK, so you are assuming that 1) virus writer will write a variant of bagle and 2) variant will have a different logic such that |43 ff ff ff ...| actually triggers a 'malicious' action instead of a cleansing action 3) The purported logic of the two steps above would be to subvert Nessus (and other scanners which cleanse the virus) and trick it into doing something malicious (albeit intended by the virus writer). I mean, you do have to make the assumption that the virus writer intends for the 'backdoor logic bomb' to be triggered, no? This all begs the questions: why would the virus writer not just perform the nasty behavior to begin with? assuming the above can be adequately explained, why would the virus writer only target systems scanning with the whacky hex string? why not get more bounce for the ounce and trigger on a 'GET /.*' command? I mean, if you trigger on GET commands, now you can coerce retina, foundscan, nessus, etc. into triggering the logic bomb (presupposing that such a coersion is necessary). John Lampe jwlampe -at- nessus.org http://f00dikator.aceryder.com/ _______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus
