From owner-freebsd-bugs Mon Oct 8 19:20: 9 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 8E5FF37B407 for ; Mon, 8 Oct 2001 19:20:05 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f992K5X47373; Mon, 8 Oct 2001 19:20:05 -0700 (PDT) (envelope-from gnats) Date: Mon, 8 Oct 2001 19:20:05 -0700 (PDT) Message-Id: <200110090220.f992K5X47373@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: tburgess@whitley.unimelb.edu.au Subject: Re: kern/31130: ipfw tee functionality causes malfunction and security hole Reply-To: tburgess@whitley.unimelb.edu.au 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: tburgess@whitley.unimelb.edu.au To: cristjc@earthlink.net, tburgess@whitley.unimelb.edu.au Cc: freebsd-gnats-submit@FreeBSD.ORG, tburgess-sent@whitley.unimelb.edu.au Subject: Re: kern/31130: ipfw tee functionality causes malfunction and security hole Date: Tue, 9 Oct 2001 12:15:52 +1000 (EST) OK, sorry for the cloudy explanation. Yeah ipfw says the packet is accepted. But what i mean is: We have a machine with interfaces 203.5.71.6, 10.0.0.1 and others. It forwards packets between the inside network and outside network, through natd. It also runs a webserver, squid proxy etc. if 10.0.1.53 (me) tries to access a webpage, say 64.1.2.3:80. The packet actually gets accepted by the apache server on the gateway machine!! So the packet is 'accepted' but not in the normal sense of the firewall 'accepting' the packet. It's original destination is just completely ignored. The daemon listening on 8665 is a traffic accounting program I have written. It does not inject any packets back into the socket. In fact, the behaviour is reproducible even when the userspace program is not running (ie the packets from the tee are getting blackholed). Hope this helps to clarify things... I'll see if I can get a tcpdump of the behaviour in a few days. Since it's a relatively important machine, I'll have to set up the firewall rules to only create the problem for me and then do it. Thanks for your help, Tim ---- Original Message ---- From: Crist J. Clark Date: Mon 10/8/01 20:24 To: Tim Burgess Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: kern/31130: ipfw tee functionality causes malfunction and security hole On Mon, Oct 08, 2001 at 02:14:18AM -0700, Tim Burgess wrote: [snip] > >Description: > It looks to me like using the ipfw 'tee' function on incoming packets actually accepts the packets as destined for the localhost. Hence a rule such as: > > 600 tee 8665 ip from any to any in > > Means that anyone browsing the web on the subnet behind the gateway sees the gateway machine's webserver no matter which url they enter. www.hotmail.com/wi actually goes to www.whitley.unimelb.edu.au/wi ! I am not sure what you are saying here. The fact that the original packet is accepted is clearly documented in ipfw(8). Not ideal behavior, but documented behavior. As for this issue where you believe that you have redirected packets, what is listening on 8665/divert? Can we see a tcpdump(8) of this behavior? -- 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