anonymous SMB service DoS on nt5 (and TCP DoS on nt4) (fwd)

[lkcl () SAMBA ORG (Luke Kenneth Casson Leighton)]

been aware of a DoS attack against NT that i originally thought was
SMB-related, for well over a year, now.  source code has been available
for this length of time, too.

what you do is send SMB requests _without_ reading the responses back.  i
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.  at least, those that
i recall checking [last year].

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.

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

i am told that this is technically quite a difficult problem to code
defensively against [clients being unfriendly and not emptying the
servers' outgoing TCP buffer].  (in which case, i do not understand why
samba does not have the same problem.  actually, that's not true - i do
know why: 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.  i am told that
it may be possible to use a TCP socket option - if winsock supports them -
to increase the unfriendly-client's TCP buffer size.

all the best,

luke

<a href=" mailto:lkcl () samba org" > Luke Kenneth Casson Leighton    </a>
<a href=" http://cb1.com/~lkcl";  > Samba and Network Development   </a>
<a href=" http://samba.org";      > Samba Web site                  </a>

ISBN1578701503 DCE/RPC over SMB: Samba and Windows NT Domain Internals