On Thu, Jan 22, 2004 at 09:26:48AM -0500, Thomas Reinke wrote:
> >It does not /start to modify things/, it just disables _a_ virus and let
> >you know that you should have a look at the remote host. The plugin is
> >also marked as being DESTRUCTIVE, ie: it will only run if safe checks are
> >disabled. Other plugins, when run in non safe checks, will have the side
> >effect of disabling other services, like nfsd or more, which might be
> >critical for a production server.
>
> 1) Does this virus DISABLE or REMOVE itself with this test?
> If it REMOVEs itself, then it does /start to modify things/.
> If it disables, then the wording in the test is misleading at
> best, or just plainly wrong at worst.
>
It removes itself, but leaves the registry keys unaltered.
> >It's not like the command is dangerous either - ie: we're not sending a
> >find -name *.pif -exec rm {} \; to the remote host, we just tell the
> >virus to stop spreading.
>
> Um, no. The script takes an action that will result in the removal of
> file(s) off the remote system under the control of code in the virus.
Okay. In the case of beagle, could you please tell me what is wrong in
that ?
> While you may get away with this once, twice, or even more often,
> eventually we are going to get bitten by this philosopy.
Specific example please ?
> >What is your real concern ? Do you think that there are production servers
> >out there which won't work properly without having beagle running ?
> >
>
> I think my real concern has already been stated. But I will repeat it.
> As a philosphy, I believe it to be prudent to minimize the execution
> of any untrusted code on the remote system. This is regardless of
> whether or not the remote host has been compromised or not.
>
> Chew on this for a moment: what is the difference between this test,
> where we knowingly execute a command that removes a file from the remote
> system, and doing the same thing if we find the box has been rooted and
> we have a command shell, and issuing "rm" commands to remove known
> viruses in known locations? Should we have a complete class of tests
> that takes advantage of remote shells, downloads software so that we
> can get a better view of the system (e.g. get a list of all rpm's
> installed, etc.) If not, why not?
A compromised system is not necessarily using 100% of its CPU time and
bandwidth replicating itself as much as it can. Bagle does, and that's
my concern. Also, issuing "rm" commands is different than sending a
specially designed command to the remote host.
Once again, _in the case of the bagle virus_ I don't see where the
harm is.
Finally, I encourage you to read the source code of win_trinoo.nasl,
which was written back in 2001, and which disables the remote trinoo
drone as well. bagle_remover is the second plugin which does that, if
you call that a slippery slope, then I think we have some time before
the next time is coming.
-- Renaud
_______________________________________________
Nessus mailing list
[EMAIL PROTECTED]
http://mail.nessus.org/mailman/listinfo/nessus