From: David LeBlanc <dleblancat_private> There appears to be some misunderstanding on your part. As I'm sure you're aware, there are often several different ways to check for a given problem. Sometimes we check for the same hole using more than one method, and in other cases, we don't have _all_ the methods which are possible. It is certainly our goal to have a totally comprehensive, perfectly reliable network auditing tool, but given the rate at which new bugs come out, the number of programmers we have, and the fact that they need to sleep once in a while, it might take us a bit longer to achieve perfection. Sorry if someone was confused and told you that the _bug_ was related to SNMP - our detection method certainly utilizes SNMP. I may have misunderstood the problem, but it seems to me that, if you can't communicate with the device (you mention trying via SNMP & logging in), then you should report it as "not tested completely, due to inability to connect" or some such message. Does the tool do this, or does it report the device as being ok?? The example someone else gave of an NT box that has been patched with SP4, but then has the TCP/IP drivers off of the original CD re-installed is an example of a different potential problem. You *must* check something on the machine being examined that can tell you *conclusively* whether or not the hole exists. Checking whether SP4 was installed is not sufficient -- you have to check the DLLs, registry settings, or whatever. If you can't perform this check due to lack of access, you should report it as such, or report that the machine "appears to not be vulnerable," and define what that means in the documentation. How does ISS handle the NT example referenced above?? -- -- Bill Van Emburg Quadrix Solutions, Inc. Phone: 732-235-2335, x206 (bveat_private) Fax: 732-235-2336 (http://quadrix.com) "You do what you want, and if you didn't, you don't"
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:12 PDT