Date: Mon, 8 Oct 2001 02:14:18 -0700 (PDT) From: Tim Burgess <tburgess@whitley.unimelb.edu.au> To: freebsd-gnats-submit@FreeBSD.org Subject: kern/31130: ipfw tee functionality causes malfunction and security hole Message-ID: <200110080914.f989EIh38572@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 31130
>Category: kern
>Synopsis: ipfw tee functionality causes malfunction and security hole
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Oct 08 02:20:02 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Tim Burgess
>Release: 4.2-RELEASE
>Organization:
Whitley College
>Environment:
FreeBSD death.whitley.unimelb.edu.au 4.2-RELEASE FreeBSD 4.2-RELEASE #4: Tue Sep
4 21:42:46 EST 2001 tburgess@death.whitley.unimelb.edu.au:/usr/src/sys/com
pile/DEATH i386
>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 !
Outgoing packets are fine.
>How-To-Repeat:
See above
>Fix:
Here is my experimental fix (untested, but it gives you an idea of what I think the problem is). I will test it when I have a chance to bring down the (relatively important to us) machine for a little while.
(from netinet/ip_input.c)
/* If 'tee', continue with original packet */
if (clone == NULL)
return;
m = clone;
ip = mtod(m, struct ip *);
Then normally it just keeps going in the 'ours' section of the code, which might explain the observed phenomena. I think something along the lines of:
/* TJB added this as an experimental bug fix */
/* make sure we don't divert again - just accept the packet*/
divert_info = 0;
goto pass;
Note that ideally the packet SHOULD continue processing through the firewall but looking at the way the code is put together I can understand why this is nontrivial. Oh well :( Maybe it's possible to export the divert_out function from ip_divert.c and call it to reinject the duplicated packet immediately?
>Release-Note:
>Audit-Trail:
>Unformatted:
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?200110080914.f989EIh38572>