Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Oct 2001 02:40:01 -0700 (PDT)
From:      "Crist J. Clark" <cristjc@earthlink.net>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/31130: ipfw tee functionality causes malfunction and security hole
Message-ID:  <200110100940.f9A9e1e91417@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/31130; it has been noted by GNATS.

From: "Crist J. Clark" <cristjc@earthlink.net>
To: Tim Burgess <tburgess@whitley.unimelb.edu.au>
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110100940.f9A9e1e91417>