From owner-freebsd-security Thu Mar 5 23:03:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA18736 for freebsd-security-outgoing; Thu, 5 Mar 1998 23:03:15 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from joshua.enteract.com (joshua.enteract.com [207.229.129.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA18173 for ; Thu, 5 Mar 1998 23:01:53 -0800 (PST) (envelope-from tqbf@secnet.com) From: tqbf@secnet.com Received: (qmail 20696 invoked by uid 1004); 6 Mar 1998 07:01:51 -0000 Message-ID: <19980306070151.20695.qmail@joshua.enteract.com> Subject: DIVERT Sockets... To: freebsd-security@FreeBSD.ORG Date: Fri, 6 Mar 1998 01:01:51 -0600 (CST) Reply-To: tqbf@secnet.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hey there. I have a question, hopefully not a heads-up: IP "divert" processing in ip_input() causes IP option processing to be skipped (basically, "divert" sockets are just a "goto" in the IP processing code that say "process this packet as if it was ours"). I am wondering if y'all see the same problem I do here, which is that IPDIVERT doesn't reset ip_nhops to zero before "accepting" packets for input. Recall that "ip_nhops" specifies whether the current packet causes a source route to be recorded; if ip_nhops is nonzero, ip_srcroute will return a reversed recorded route from the last accepted source-routed packet. Each time a new valid packet is accepted, "ip_nhops" is supposed to be reset to zero. The TCP input code blindly calls ip_srcroute() when a connection is being established to see if the SYN connection-soliciting packet was source routed; if it was, it uses the recorded route for all future packets for this connection. Because of the IPDIVERT hack, it seems to me that anyone can send a source routed packet right before a diverted SYN packet, and that SYN packet will follow the reverse of the source route. On networks that don't drop source routed packets, this would allow remote attackers to hijack arbitrary connections remotely without direct network access to the path those connections take. I don't know enough about IPDIVERT to tell if this is the case; I am trying to wade through the code to see if divert sockets modifies IP output not to send source routed packets. ----------------------------------------------------------------------------- Thomas H. Ptacek Secure Networks, Inc. ----------------------------------------------------------------------------- http://www.enteract.com/~tqbf "mmm... sacrilicious" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message