From owner-freebsd-bugs Wed Oct 10 2:40:12 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0496E37B407 for ; Wed, 10 Oct 2001 02:40:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9A9e1e91417; Wed, 10 Oct 2001 02:40:01 -0700 (PDT) (envelope-from gnats) Date: Wed, 10 Oct 2001 02:40:01 -0700 (PDT) Message-Id: <200110100940.f9A9e1e91417@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: "Crist J. Clark" Subject: Re: kern/31130: ipfw tee functionality causes malfunction and security hole Reply-To: "Crist J. Clark" Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/31130; it has been noted by GNATS. From: "Crist J. Clark" To: Tim Burgess Cc: freebsd-gnats-submit@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: kern/31130: ipfw tee functionality causes malfunction and security hole Date: Wed, 10 Oct 2001 02:35:47 -0700 On Tue, Oct 09, 2001 at 02:20:02AM -0700, Crist J. Clark wrote: [snip] > On the wire and the packets never get routed to the "real" 172.16.0.1. > Trying to figure out if, > > a) This is the expected behavior, but is poorly documented, or > b) Something is broken. > > I'm thinking (b), but still wading through src/sys/netinet to verify. Well, I see why this happens, but still not sure if it is supposed to happen. If we look at src/sys/netinet/ip_input.c, we see that all diverted or teed packets are accepted by the host as destined for itself, #ifdef IPDIVERT if (i != 0 && (i & IP_FW_PORT_DYNT_FLAG) == 0) { /* Divert or tee packet */ divert_info = i; goto ours; } #endif The packets are clearly going to be processed by the gateway. You seem to have already found this in the code snipped in your original PR, but I didn't notice your change. Please post changes to code as unified diffs. I now understand the 'fix' you were talking about. Have you actually built a kernel with your modifications? Does it seem to work? But packets _leaving_ the system seem to be processed as one would expect. That is, a copy is divert(4)ed and then the packet heads out onto to the wire. This apparent inconsistency is a bug since it is either unintended behavior or at least undocumented behavior. But the inconsistency gives you a temporary workaround. Instead of, 600 tee 8665 ip from any to any in Does, 600 tee 8665 ip from any to any out Work as you would expect? -- Crist J. Clark cjclark@alum.mit.edu cjclark@jhu.edu cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message