Bug 19722
| Summary: | FreeBSD box responds to broadcast IP | ||
|---|---|---|---|
| Product: | Base System | Reporter: | radius <radius> |
| Component: | kern | Assignee: | Robert Watson <rwatson> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 3.4-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
radius
2000-07-06 03:30:00 UTC
Responsible Changed From-To: freebsd-bugs->rwatson Bug confirmed, and present when non-forwarding and non-ipfw on 4.0-STABLE, 4.0-CURRENT from a year ago. 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 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. 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 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. |
