i386/148458: FreeBSD device can be used as an unintentional router between two or more network(s).

Paul-Andrew Joseph Miseiko pmiseiko at gmail.com
Fri Jul 9 01:00:12 UTC 2010


>Number:         148458
>Category:       i386
>Synopsis:       FreeBSD device can be used as an unintentional router between two or more network(s).
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-i386
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jul 09 01:00:11 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Paul-Andrew Joseph Miseiko
>Release:        8.1-PRERELEASE
>Organization:
>Environment:
FreeBSD teardrop.ca 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Wed Jul  7 22:18:16 EDT 2010     esoteric at teardrop.ca:/usr/obj/usr/src/sys/TEARDROP  i386
>Description:
An ICMP echo request with a spoofed source IP address can use a FreeBSD device bound to two or more network(s) as a router.  The FreeBSD device does not need IP forwarding enabled for this to work.  The problem is FreeBSD does not validate the source IP address associated with the network the ICMP echo request was received from.  The issue can also be worded that FreeBSD does not validate the ICMP echo response will be sent to the same network the ICMP echo request was received from.

The issue can be used to maliciously communicate between two networks through a FreeBSD device even if policy does not permit communication between those two networks.  For example it is possible to communicate between an Internet and an Intranet through a FreeBSD device configured as the gateway between those two networks.

The issue has been reproduced with a (otherwise forgotten) version of FreeBSD 4, with a (otherwise forgotten) version of FreeBSD 7, with FreeBSD 8.0 and with FreeBSD 8.1-PRERELEASE.
>How-To-Repeat:
Spoof the source IP address for an ICMP echo request from network A with the desired destination IP address (as the spoofed source IP address) on network B.  The ICMP echo request data can contain marshaled data to be sent between the two network(s).  The host on network B can communicate with the host on network A through the same mechanism.  This would result in a potential unexpected communication channel.
>Fix:
Solution #1:
The issue can be resolved with the IPFW verrevpath option.

Example:
deny log ip from any to me in recv any not verrevpath

Solution #2:
The code in "sys/netinet/ipfw/ip_fw2.c" "static int verify_path(struct in_addr src, struct ifnet *ifp, u_int fib)" can be used/referenced/called in "sys/netinet/ip_icmp.c" "void icmp_input(struct mbuf *m, int off)" to resolve this issue.

"static int verify_path(struct in_addr src, struct ifnet *ifp, u_int fib)" can be made not static and moved into a different file since it might not be available if the kernel is not compiled with IPFIREWALL support.

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-i386 mailing list