Re: Comments re: Vulnerability Analysis

From: tqbf (ashlandat_private)
Date: Sat Feb 13 1999 - 23:57:47 PST

  • Next message: Eric Stevens: "Re: Another Windows98 Bug..."

    My apologies for sending this to the list in the first place; hopefully
    this will be the last time I have to do it, and the thread will end here.
    However, some very bizarre claims have been made about my work and I find
    it necessary to address them.
    
    Regarding <mroat_private>'s claims about our scanner:
    
    1.) The assertion that information gathering checks need to be enabled for
        SMTP checks to work is simply false. I don't know who told him this
        (maybe our much-vaunted tech support), but the only aspect of our
        product that relies on the information gathering checks is the network
        map. My expectation is that this person has run into a condition in
        his operating environment that is either tickling a bug in our code
        or breaking connectivity to his servers. This is the first I've heard
        of it.
    
    2.) We do in fact have SMTP server checks that rely on banner grabs. One
        obvious one is the "Sendmail banner check", which is intended to alert
        admins THAT SMTP banners are present (and nothing more). At least one
        other SMTP check relies on Sendmail banners being present to infer a
        vulnerability; there was no other option to implement this check, and
        my understanding is that the inference nature of the check is
        disclaimed.
    
    3.) Using "netcat" as a fake SMTP server will trip our buffer overflow
        modules if netcat behaves identically to a downed SMTP daemon.
        Specifically, if, after receiving the exploit buffer, netcat exits
        (due to a CTR-C or whatnot), the scanner will notice the closed
        connection, and will assume it "killed" the SMTP server. The only
        condition I can imagine where a sudden connection closure, in
        immediate response to a buffer overflow attempt, does NOT indicate
        a problem is when someone is specifically trying to fool the scanner.
    
    I'd be happy to address any further issues about our product offline.
    
    Again, sorry for the noise pollution.
    
    -----------------------------------------------------------------------------
    Thomas H. Ptacek     			  Network Security Research Team, NAI
    -----------------------------------------------------------------------------
    	   		         "If you're so special, why aren't you dead?"
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:34:38 PDT