I too don't know that I agree one way or another with either side of this discussion.

I think that someone coding malicious variant would be more likely to modify an existing command to do something "bad" when the results of the original command are expected to be relatively "good" Let's face it, to a lot of people, deception is fun.
I agree that it is a good idea to disable beagle to prevent spreading.


It's much easier to
-draw a line saying that Nessus shouldn't fix anything
than it is to
-manage a gray area where Nessus fixes some things and not others.
How would it be determined which "fixes" are allowed in plugins?

In this case, I don't see a problem with a plugin disabling beagle. I agree with the "slippery slope" that was mentioned previously. Maybe there needs to be a "Fix/disable vulnerabilities when possible" checkbox added to Nessus. (but I guess that would go against the "Nessus is a vulnerability _scanner_" philosophy)

Mike


Okay. In the case of beagle, could you please tell me what is wrong in
that ?

What about beagle variants that change the expected behavior?


I thought about that, and that actually hold me off at first. However
when you think about it, you could have a beagle variant which wipes the
disk if it receives an HTTP GET request on its port, or if a port
scanner connects to it and closes the connection, or whatever.

So yeah, variants could be naughty, but then again they don't simply
have to be naughty _when_ they receive a specific beagle command.


-- Renaud _______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus

_______________________________________________ Nessus mailing list [EMAIL PROTECTED] http://mail.nessus.org/mailman/listinfo/nessus

Reply via email to