ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Ilia Sprite                          2:5080/112.7   05 Jun 2000  15:06:06
 To : All
 Subject : кто тут дыры к nt5 коллекционирует?
 -------------------------------------------------------------------------------- 
 

 
 
 === Hачало минного поля ===
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
 Date: Вё, 04 шюэ 2000  22:55:59
     From: Luke Kenneth Casson Leighton <lkcl@SAMBA.ORG>
       To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
  Subject: anonymous SMB service DoS on nt5 (and TCP DoS on nt4)
 ------------------------------------------------------------------------------- 
 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
 === Конец минного поля ===
     Tiddely pom...
 --- NP: nothing
  * Origin: VGA Planets BBS (2:5080/112.7)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор