At 07:15 PM 2/8/99 +0100, l41484at_private wrote: >While i've never used the product, it seems to me, that from the quote, >the product is giving misleading information. Since (from what i've seen) >the product hasn't been able to determine if the router in question is >vulnerable or not, it shouldn't report that it's safe. It should report, >that vulnerability is unknown, which is a lot different than safe. That's a misunderstanding. You can get false negatives for a large number of often unpreventable reasons. Basically, you can assume that if we report it as vulnerable, then it _is_ vulnerable (barring false positive bugs). If we do not report it as vulnerable, then it may not be vulnerable. As I'm sure anyone writing code in this area can confirm, this is a really tough problem - the huge number of implementations of various services, network mayhem, etc makes perfection very elusive. This is why we _don't_ tell you the box is safe - we just tell you what we can find that tells us it _isn't_. Kind of like how you can prove a crypto algorithm is broken, but you can't prove it isn't. One example of just how hard all of this is came to my attention yesterday - we scanned an HP box running the AT&T port of the NT services. The $%#@!! thing _looked_ almost exactly like an NT box, down to giving up the users, and reporting running services. So we go thinking it _is_ an NT box, and then the lack of certain registry keys would imply a vulnerability on an NT machine, so we get false positives... You run into the same sort of logic when doing a UDP port scan - you can't tell conclusively if the port is listening, just that it isn't. You'll sometimes get cases where you think there is something there, and it isn't. David LeBlanc dleblancat_private
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:33:33 PDT