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

Type securityvulns
Reporter Securityvulns
Modified 2000-06-05T00:00:00


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,


<a href="" > Luke Kenneth Casson Leighton </a> <a href="" > Samba and Network Development </a> <a href="" > Samba Web site </a>

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