From owner-freebsd-hackers Thu Jun 1 17:36:09 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA16799 for hackers-outgoing; Thu, 1 Jun 1995 17:36:09 -0700 Received: from tfs.com (mailhub.tfs.com [140.145.250.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA16793 for ; Thu, 1 Jun 1995 17:36:08 -0700 Received: by tfs.com (smail3.1.28.1) Message-Id: From: julian@TFS.COM (Julian Elischer) Subject: I call it the "NT sniper bug". (fwd) To: hackers@FreeBSD.ORG Date: Thu, 1 Jun 1995 17:35:37 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3856 Sender: hackers-owner@FreeBSD.ORG Precedence: bulk Just say no.. I'm sure we might all bare this one in mind I bet we'll hear about it sometime > > Date: Mon, 29 May 1995 15:05:06 -0400 > Forwarded-by: bostic@CS.Berkeley.EDU (Keith Bostic) > Subject: I call it the "NT sniper bug". > > Forwarded-by: matthew green > Forwarded-by: Richard Michael Todd > Forwarded-by: randy@ux1.cso.uiuc.edu (Randall E. Cotton) > > langner@seufert.de (Ernst Langner) writes: > > > In our network I've sometimes seen the ICMP Message "host unreachable". > > It was generated by a PC running Windows NT 3.5. There was trafic between > > two stations e.g. two sun workstations. The NT PC sends the ICMP message > > to one of the sun stations unmotivated. Such messages are normaly > > generated by gateways, I can't find any reason for a station in a LAN > > environment to generate such a message. It seems to be a bug. The sun > > workstation ignores this ICMP message. But we are using some X terminals > > too. They believe what the message says and break down a session. > > YES, YES, YES! > > I just recently saw this here at University of Illinois, Urbana/Champaign. > I call it the "NT sniper bug". A UNIX software distribution process > between subnets in different buildings was consistently and inexplicably > failing at what appeared to be random times. Analysis of the traffic > (Network General Sniffer) showed the cut connections were due to an ICMP > type 3 (Destination Unreachable) code 1 (Host Unreachable) packet. > According to the ICMP spec (RFC792), such packets may only be sent from > routers. I assumed the source was indeed a router and perhaps there was > a problem with the network in the other building. When I learned it was > a PC, I was intrigued to say the least. > > After travelling to the other building, tracking down the offending > machine and seeing that all it was running was NT, I didn't even > believe my eyes at first ("gotta be an IP address conflict", I said to > myself, "something else has got to be the culprit"). But thorough > testing (again, with a Sniffer) prooved it beyond any doubt... > > Every once in a while at what appeared to be random intervals, this > machine was choosing an apparently arbitrary IP packet on the Ethernet > (regardless of its addressed destination) and generating an ICMP host > unreachable error packet to its source, dutifully including the first > portion of the victim packet. > > This bug is truly subtle and insidious. It's as if NT, disguised as an > innocent user-friendly operating system, is surreptitiously playing > "network sniper", firing off single-packet shots that can trash > arbitrary TCP connections present on or passing through the immediately > attached net. I bet most people that have it don't even know it. > > By the way, the reason why it must be a bug is threefold: > > First of all, NT shouldn't even be *aware* of traffic that isn't > addressed to it. my own theory is that the host being shot at is brave enough to have sent out a 'arp request' as it's own arp table entry for the other machine had just timed out... [JRE] hmm wonder if uSoft want to make all other machines appear unreliable :) > Secondly, any such packet that errantly makes it to > NT's TCP/IP stack *should* be ignored by that stack. Thirdly, an NT > workstation, not being a router, absolutely should never send an ICMP > host unreachable packet. Pretty hoarked, if you ask me. > > If anyone else has seen this behavior, please send me e-mail, or better > yet, reply to the group - it may be of wide interest. I'd like to band > together, if possible, to figure out a solution - dealing with MS Tech > Support on this is not exactly high on my list of strategies. > > Randall Cotton > Network Analyst > University of Illinois > Network Administrator Support >