From radius@resurrection.oznetcom.com.au Wed Jul 5 19:22:08 2000 Return-Path: Received: from resurrection.oznetcom.com.au (resurrection.oznetcom.com.au [203.18.50.11]) by hub.freebsd.org (Postfix) with ESMTP id 3F22C37B6A8 for ; 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 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" 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: