COMMAND

    SMB

SYSTEMS AFFECTED

    WinNT 4, 5

PROBLEM

    Luke Kenneth Casson Leighton found following.  What you do is send
    SMB  requests  _without_   reading  the  responses   back.    Luke
    originally thought that  you had to  send SMBtrans IPC$  requests,
    but it turns out  that just a series  of SMBnegprots will do,  and
    on port 445 an SMBnegprot is the first packet sent, so a repro  of
    this is, like, _really_ intellectually challenging.

    On NT4,  the consequence  is that  the entire  TCP/IP stack on all
    ports refuses to accept any further incoming connections.

    On NT5, the consequence is  that if the (single) connection  (with
    the backed-up  requests still  unprocessed because  the client  is
    being unfriendnly and not  reading the responses from  the server)
    is maintained, the SMB server is unavailable.  All other  services
    are available.  Outgoing connections (except to its own SMB server
    on loopback) are unaffected.

    On  NT5,  the  SMB  server  is  unavailable until 20 seconds after
    termination of the  rogue connection.   i.e. 20 seconds  after the
    connection is  terminated, the  SMB server  becomes available  and
    accepts  further  incoming  connections.   port  445,  port   139,
    doesn't matter.

    Luke did not do  an analysis of any  other ports or services.   He
    expected there to  be other NT  services affected by  this kind of
    attack         that         are         implementations         of
    request-response-request-response...  interleaved protocols.

    Samba doesn't have  this probleam as  samba forks one  process per
    incoming connection, so  if a single  client wants to  screw their
    own connection, they can do so as much as they like  (speculation:
    problem  likely  to  be  related  to  threaded  or  kernel   level
    implementation of server: service dependent on TCP stack blocking.
    Other such services implemented  in similar manner also  likely to
    be affected).

    One final note: the problem can *not* be reproduced using standard
    user-space winsock, at least, with the default settings.   It  may
    be possible to use a TCP socket option - if winsock supports  them
    - to increase the unfriendly-client's TCP buffer size.

SOLUTION

    Nothing yet.