From radius@resurrection.oznetcom.com.au  Wed Jul  5 19:22:08 2000
Return-Path: <radius@resurrection.oznetcom.com.au>
Received: from resurrection.oznetcom.com.au (resurrection.oznetcom.com.au [203.18.50.11])
	by hub.freebsd.org (Postfix) with ESMTP id 3F22C37B6A8
	for <FreeBSD-gnats-submit@freebsd.org>; Wed,  5 Jul 2000 19:22:03 -0700 (PDT)
	(envelope-from radius@resurrection.oznetcom.com.au)
Received: (from radius@localhost)
	by resurrection.oznetcom.com.au (8.9.3/8.9.3) id MAA08187;
	Thu, 6 Jul 2000 12:21:56 +1000 (EST)
Message-Id: <200007060221.MAA08187@resurrection.oznetcom.com.au>
Date: Thu, 6 Jul 2000 12:21:56 +1000 (EST)
From: radius@oznetcom.com.au
Sender: radius@resurrection.oznetcom.com.au
Reply-To: radius@oznetcom.com.au
To: FreeBSD-gnats-submit@freebsd.org
Subject: FreeBSD box responds to broadcast IP
X-Send-Pr-Version: 3.2

>Number:         19722
>Category:       kern
>Synopsis:       FreeBSD box responds to broadcast IP
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    rwatson
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 05 19:30:00 PDT 2000
>Closed-Date:    Mon Mar 18 11:07:07 PST 2002
>Last-Modified:  Mon Mar 18 11:07:07 PST 2002
>Originator:     M P Hibbard
>Release:        FreeBSD 3.4-STABLE i386
>Organization:
Davnet Telecommunications Pty Ltd
>Environment:

FreeBSD running as a gateway for between networks.  Seems to work
on tested versions from 3.4S (June 22), and recent 4.0S.

In the situation described below, the test machine was running 4.0-STABLE
with IPF, IPFW and DUMMYNET in the kernel.

>Description:

If FreeBSD is running as a gateway for between two networks, and packets
from one network are travelling to the other network's broadcast address
the FreeBSD gateway will intercept them and interpret them as if they
were destined for itself.

This could possibly allow an attacker to bypass firewall rules by sending
packets to the broadcast address of a network being firewalled by a FreeBSD
gateway - the FreeBSD gateway might allow the packets directly through to it
as the firewall rules may not allow for this situation.

>How-To-Repeat:

FreeBSD box at 203.62.175.1, gateway on a dialup connection with the
network 203.62.175.0/24 routed to it.

From a network outside of 203.62.175.1, past the dialup gateway:

	radius@resurrection:~$ telnet 203.62.175.255
	Trying 203.62.175.255...
	Connected to 203.62.175.255.
	Escape character is '^]'.

	FreeBSD/i386 (scythe.darktide.net) (ttyp0)

	login:

We get a connection to the gateway box itself, 203.62.175.1.

This has been tested with different packets, TCP/UDP/ICMP.  ICMP seems a bit
weird.  A ping to 203.62.175.255 from inside the network 203.62.175.0/24
and the .1 machine will not respond, however, from outside it, ONLY .1 will
respond even if other machines -would- have responded normally.

This has also been tested on other network configurations with up to 7
network interfaces.

It also seems to work regardless of whether IPFW has been compiled into
the kernel.

>Fix:
	
none known

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->rwatson 
Responsible-Changed-By: rwatson 
Responsible-Changed-When: Wed Jul 5 19:39:19 PDT 2000 
Responsible-Changed-Why:  
Bug confirmed, and present when non-forwarding and non-ipfw on 4.0-STABLE, 
4.0-CURRENT from a year ago. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19722 

From: Robert Watson <rwatson@freebsd.org>
To: radius@oznetcom.com.au, jayanth@yahoo-inc.com
Cc: peter@freebsd.org, FreeBSD-gnats-submit@freebsd.org,
	kris@freebsd.org
Subject: kern/19722: FreeBSD box responds to broadcast IP (fwd)
Date: Wed, 5 Jul 2000 22:54:32 -0400 (EDT)

 This seems pretty serious, and I have confirmed with FreeBSD 4.0-STABLE
 from USENIX, and FreeBSD 4.0-CURRENT from about the same time last year.
 
 Config setup that I reproduced:
 
 
          +-------------------------------------+
     192.168.3.3                            192.168.3.40
                                            192.168.254.1
                                                |
                                            192.168.243.2  (vmware)
 
 
 192.168.3.3 has a 192.168.254/24 route via 192.168.3.40.  192.168.3.3 can
 telnet to 192.168.254.255 and get a response the 192.168.3.40 box, both
 when ip forwarding is enabled and disabled, and with both ipfw enabled and
 disabled.  ICMP also seems to work.  Have not tested UDP.
 
 I also reproduced in the following situation:
 
          +---------------------------------------------+
     192.168.3.3                                   192.168.3.40
     151.200.24.159
 
 Wherein 192.168.3.40 would send packets to 151.200.24.255.
 
 This is a risk for a number of reasons.
 
   (1) non-local access to the broadcast address sucks for DoS reasons if
 none else, and is generally inappropriate, especially for TCP
 
   (2) firewall rules typically don't account for TCP connections to
 broadcast addresses (which are probably inappropriate anyway)
 
   (3) when IP forwarding is disabled, a machine should not respond to
 packets on an interface if the packets are to an address not local to that
 interface. 
 
 So it looks like this behavior is confirmed on 3.4-STABLE, 4.0-STABLE, and
 presumably 5.0 by implication.  It seems to me that there a number of
 aspects to this that need fixing, addressing the various concerns above --
 inappropriate response to packets on the wrong interface, inappropriate
 response to a broadcast address (TCP in particular).  I guess I'd like to
 see confirmation from another third party that (a) this occurs, and (b)
 that they consider it a problem.
 
   Robert N M Watson 
 
 robert@fledge.watson.org              http://www.watson.org/~robert/
 PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
 TIS Labs at Network Associates, Safeport Network Services
 
 ---------- Forwarded message ----------
 Date: Thu, 6 Jul 2000 12:21:56 +1000 (EST)
 From: radius@oznetcom.com.au
 To: FreeBSD-gnats-submit@freebsd.org
 Subject: kern/19722: FreeBSD box responds to broadcast IP
 
 
 >Number:         19722
 >Category:       kern
 >Synopsis:       FreeBSD box responds to broadcast IP
 >Confidential:   yes
 >Severity:       critical
 >Priority:       high
 >Responsible:    freebsd-bugs
 >State:          open
 >Quarter:        
 >Keywords:       
 >Date-Required:
 >Class:          sw-bug
 >Submitter-Id:   current-users
 >Arrival-Date:   Wed Jul 05 19:30:00 PDT 2000
 >Closed-Date:
 >Last-Modified:
 >Originator:     M P Hibbard
 >Release:        FreeBSD 3.4-STABLE i386
 >Organization:
 Davnet Telecommunications Pty Ltd
 >Environment:
 
 FreeBSD running as a gateway for between networks.  Seems to work
 on tested versions from 3.4S (June 22), and recent 4.0S.
 
 In the situation described below, the test machine was running 4.0-STABLE
 with IPF, IPFW and DUMMYNET in the kernel.
 
 >Description:
 
 If FreeBSD is running as a gateway for between two networks, and packets
 from one network are travelling to the other network's broadcast address
 the FreeBSD gateway will intercept them and interpret them as if they
 were destined for itself.
 
 This could possibly allow an attacker to bypass firewall rules by sending
 packets to the broadcast address of a network being firewalled by a FreeBSD
 gateway - the FreeBSD gateway might allow the packets directly through to it
 as the firewall rules may not allow for this situation.
 
 >How-To-Repeat:
 
 FreeBSD box at 203.62.175.1, gateway on a dialup connection with the
 network 203.62.175.0/24 routed to it.
 
 From a network outside of 203.62.175.1, past the dialup gateway:
 
 	radius@resurrection:~$ telnet 203.62.175.255
 	Trying 203.62.175.255...
 	Connected to 203.62.175.255.
 	Escape character is '^]'.
 
 	FreeBSD/i386 (scythe.darktide.net) (ttyp0)
 
 	login:
 
 We get a connection to the gateway box itself, 203.62.175.1.
 
 This has been tested with different packets, TCP/UDP/ICMP.  ICMP seems a bit
 weird.  A ping to 203.62.175.255 from inside the network 203.62.175.0/24
 and the .1 machine will not respond, however, from outside it, ONLY .1 will
 respond even if other machines -would- have responded normally.
 
 This has also been tested on other network configurations with up to 7
 network interfaces.
 
 It also seems to work regardless of whether IPFW has been compiled into
 the kernel.
 
 >Fix:
 	
 none known
 
 >Release-Note:
 >Audit-Trail:
 >Unformatted:
 
 
 To Unsubscribe: send mail to majordomo@FreeBSD.org
 with "unsubscribe freebsd-bugs" in the body of the message
 
 
State-Changed-From-To: open->suspended 
State-Changed-By: rwatson 
State-Changed-When: Mon Mar 19 11:43:11 PST 2001 
State-Changed-Why:  

Fixes for this problem are under-way: support for the strong ES model 
check interface is being implemented.  A short-term solution involves 
the newly introduced net.inet.ip.check_interface which forces the IP 
stack to accept packets only on addresses appropriate for the interface. 
Use of this flag is recommended on firewalls, and documentation should 
be updated to reflect that. 

I'm going to move the PR to suspended, but report back on it as strong 
ES becomes available. 



http://www.freebsd.org/cgi/query-pr.cgi?pr=19722 

From: "Crist J. Clark" <crist.clark@attbi.com>
To: rwatson@freebsd.org
Cc: bug-followup@freebsd.org
Subject: kern/19722: FreeBSD box responds to broadcast IP
Date: Mon, 25 Feb 2002 00:30:14 -0800

 I believe this bug was fixed by ip_input.c 1.158 and tcp_input.c
 1.148.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
State-Changed-From-To: suspended->closed 
State-Changed-By: rwatson 
State-Changed-When: Mon Mar 18 11:05:39 PST 2002 
State-Changed-Why:  
This PR seems now to be largely addressed.  We now prevent multicast/ 
broadcast from going to specifically unicast IP protocols (TCP), and 
have better support for strong ES model stuff.  We still don't have 
things where we can twiddle strong/weak ES using a sysctl, but the 
person who volunteered to do that seems to have gone away.  Closing 
this PR since it seems to be effectively resolved. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=19722 
>Unformatted:
