Re: msblast.d and a review of defensive worms

From: Nicholas Weaver (nweaverat_private)
Date: Mon Aug 18 2003 - 15:50:38 PDT

  • Next message: Theo de Raadt: "Re: Buffer overflow prevention"

    On Mon, Aug 18, 2003 at 01:42:29PM -0400, David J. Meltzer composed:
    > As many people have undoubtably already seen, the newest variant of
    > msblast (dubbed msblast.d, see
    > http://www.trendmicro.com/vinfo/virusencyclo/default5.asp?VName=WORM_MSB
    > LAST.D) is one of a growing group of "good/defensive worms."  
    > 
    > As every previous "good" worm has, this will of course touch off another
    > debate on just how bad worms of this variety are.  Coincidentally
    > (really!) I have been polishing a presentation on defensive worms I will
    > be giving at Toorcon.  Since the historical portion of my presentation
    > has become so timely, I've put up that first portion of my presentation
    > on the web for anyone interested to review.  
    > 
    > It is directly linked at http://www.intrusec.com/resources.html, no
    > registration of any kind is required to read.  If you have any errata or
    > additional references, feel free to e-mail me privately and I will
    > incorporate them.
    > 
    > Here is also the list of references from this presentation for anyone
    > who just wants to go directly to the source material and skip my fluff:
    
    A couple of other comments, not really addressed in the sides.
    
    Beyond being blatently illegal, white/good worms have a couple of
    other BIG problems:
    
    They can't work against a smart "black" worm: the white worm must be
    released afterwards (otherwise, why not just use autoupdate, as there
    is "no worm required" for autoupdate to work?  Which vulnerabilities
    get white worms and which get ignored?).
    
    Unless the black worm is grossly poorly engineered, the black worm
    will have spread everywhere and had a chance to unleash its payload.
    Remember, the release of a white worm involves human intervetion (use
    the exploit, TEST, release), while viable defenses need to be
    automatic.
    
    
    
    Likewise, a black worm can easily close the hole behind it.  EG,
    slammer blocks further infection (the service is frozen into the
    sending loop).  So you can't make an anti-slammer worm, without using
    a different exploit, as slammer-infected machines are immune.
    
    Likewise, MS-blast (i think) uses the RPC crashing version of the
    exploit, so while the computer stays up, further infection by any
    means, using the RPC vector, would be impossible.
    
    So even a "lame, slow" worm like Blaster can still be resistant to a
    white-worm counterattack, simply by virtue of closing the hole it used
    behind it.  Note that this closure doesn't necessarily require
    patching, just killing/disabling the vulnerable part of the service
    used by the worm, which has happened (inadvertantly) in the past.
    
    -- 
    Nicholas C. Weaver                                 nweaverat_private
    



    This archive was generated by hypermail 2b30 : Mon Aug 18 2003 - 15:12:56 PDT