SORRY(DISCLAIMER): For this moment I don't have enough time & knowledge to explore the problem in all its deepness, so the following description could be just a a special case of the more common one. DESCRIPTION ITSELF: It seems FreeBSD's networking internals introduce new vulnerability -- network broadcast addresses may be used for communications with the system just as well as it was her own. In conjunction with using ipfw's `me'-keyword this may leave holes in hosts security, because ipfw's `me' understanding differs from other networking internals approach (in ip_input, for e.g., i.e., it may treat a packet as `ours' more widely than `me' does.) While using ipfw's `me'-keyword, one might consider using `deny tcp from any to me', for e.g., as a safe equivalent of `deny tcp from any to any except forwarded connections' but this can fail (sometimes, under circumstances not well known to me) in cases when IP-packets will be forwarded via broadcast media being destined to the network broadcast IP-address (at the networking level) and to the MAC-address of the system's NIC (at the channel level). As I said before this is because of the FreeBSD TCP/IP stack implementation features. Fix: I wrote a quick-hack-patch, making `me' to match broadcast addresses also (it is available at http://www.morning.ru/~poige/patchzone also): ----------X-8-----------X-8-----------X-8-----------X-8----------- /* * Macro for finding the internet address structure (in_ifaddr) corresponding ----------X-8-----------X-8-----------X-8-----------X-8----------- but as far as I can suppose more qualitative solution is needed. (IMHO: I'd like to have BSDi's ipfw or may be Linux 2.4 netfilter's approach in classifying of the packets and cooperating with other networking internals implemented in FreeBSD).--6wcu0T12NHvm5vHC54p2YlxQ1OJHBuVeS4qUgHmdReR3ytBQ Content-Type: text/plain; name="file.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="file.diff" --- in_var.h.org Sat Feb 16 16:23:12 2002 +++ in_var.h Sat Feb 16 23:41:21 2002 @@ -105,17 +105,26 @@ * Macro for finding the interface (ifnet structure) corresponding to one * of our IP addresses. */ -#define INADDR_TO_IFP(addr, ifp) \ - /* struct in_addr addr; */ \ - /* struct ifnet *ifp; */ \ -{ \ - struct in_ifaddr *ia; \ -\ - LIST_FOREACH(ia, INADDR_HASH((addr).s_addr), ia_hash) \ - if (IA_SIN(ia)->sin_addr.s_addr == (addr).s_addr) \ - break; \ - (ifp) = (ia == NULL) ? NULL : ia->ia_ifp; \ -} + +#define INADDR_TO_IFP(addr, ifp) \ + /* struct in_addr addr; */ \ + /* struct ifnet *ifp; */ \ +do { \ + register struct in_ifaddr *ia; \ + (ifp) = NULL; \ + for (ia = in_ifaddrhead.tqh_first; ia != NULL; \ + ia = ia->ia_link.tqe_next) \ + { \ + if ((addr).s_addr == IA_SIN(ia)->sin_addr.s_addr \ + || ia->ia_ifp && \ + ia->ia_ifp->if_flags & IFF_BROADCAST && \ + (addr).s_addr == IA_DSTSIN(ia)->sin_addr.s_addr)\ + { \ + (ifp) = ia->ia_ifp; \ + break; \ + } \ + } \ +} while (0) How-To-Repeat: try using such configuration: [box A]---ethernet---[box B] Assume network 192.168.12.0/24 lies on the ethernet, box A has 192.168.12.1, box B 192.168.12.2 On box A add route to 192.168.13.0/24 via 192.168.12.2 and start pinging 192.168.13.255 for now no response should be heard. Then add an alias 192.168.13.1 to box B's NIC. Immediately box A will hear box B responding. As my experience shows, sometimes it is even possible to (s)login, for e.g., into the B box, and have other tcp/(udp?)-services responding. It's obviously dangerous and serious.
I don't think 'me' not matching the broadcast address is in itself a problem. The example of, 'deny ip from any to me,' demonstrates why it is bad to explicitly deny. Use an explicit pass and default to deny. I also think 'me' works as advertised, Specifying me makes the rule match any IP address configured on an interface in the system. If you want to block a broadcast address in addition to the ones assigned to the interface, do so. But there was mention of another behavior that is a bug. You _can_ establish a TCP connection to a FreeBSD machine with the destination being the broadcast address. This is oh so Very Very Bad. And it breaks the Standard (the Standard being everyone's favorite, RFC1122), 4.2.3.10 Remote Address Validation ... A TCP implementation MUST silently discard an incoming SYN segment that is addressed to a broadcast or multicast address. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org
> I don't think 'me' not matching the broadcast address is in itself a > problem. I said the problem is the ip_input.c considers packets as "ours" more widely than IPFW's 'me'. > The example of, 'deny ip from any to me,' demonstrates why it > is bad to explicitly deny. Use an explicit pass and default to deny. alas, ipfw's syntax doesn't allow implement this idea cleary and flexible. whereas, BSDi's ipfw do. also as Linux 2.4 netfilter. I wrote about it before. > I also think 'me' works as advertised, yeah. it does. > Specifying me makes the rule match any IP address configured on > an interface in the system. > If you want to block a broadcast address in addition to the ones > assigned to the interface, do so. yeah, of course. I think about deny ip from any to broadcast and, may be deny ip from any to network But my patch is just a quick hack and the above requires much more skills, knowledge and time in order to implement it. So I just can't afford it for now. But certainly I'm thinking about it. > But there was mention of another behavior that is a bug. You _can_ > establish a TCP connection to a FreeBSD machine with the destination > being the broadcast address. This is oh so Very Very Bad. And it > breaks the Standard (the Standard being everyone's favorite, RFC1122), > 4.2.3.10 Remote Address Validation > ... > A TCP implementation MUST silently discard an incoming SYN > segment that is addressed to a broadcast or multicast > address. yep. BTW it declares TCP only? -- Igor M Podlesny a.k.a. Poige phone (work): +7 3912 362536 http://www.morning.ru/~poige
On Sun, Feb 17, 2002 at 03:51:23PM +0700, Igor M Podlesny wrote: [snip] > > But there was mention of another behavior that is a bug. You _can_ > > establish a TCP connection to a FreeBSD machine with the destination > > being the broadcast address. This is oh so Very Very Bad. And it > > breaks the Standard (the Standard being everyone's favorite, RFC1122), > > > 4.2.3.10 Remote Address Validation > > > ... > > > A TCP implementation MUST silently discard an incoming SYN > > segment that is addressed to a broadcast or multicast > > address. > > yep. > > BTW it declares TCP only? No, for IP datagrams in general, For most purposes, a datagram addressed to a broadcast or multicast destination is processed as if it had been addressed to one of the host's IP addresses; As for UDP, it says nothing specific about how to handle incoming datagrams with the broadcast address as the destination (it's up to the application). However, it does mention, UDP is used by applications that do not require the level of service of TCP or that wish to use communications services (e.g., multicast or broadcast delivery) not available from TCP. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org
State Changed From-To: open->analyzed Fix for establishing TCP connections to the broadcast address applied to -CURRENT. Will MFC to -STABLE and the bug fix branches (RELENG_4_?) shortly.
Responsible Changed From-To: freebsd-bugs->cjc I'll handle the merges.
State Changed From-To: analyzed->closed Fixed in -CURRENT and -STABLE. After further review of the threat, this will not be merged into the security-fix branches.
Envoy=C3=A9 de mon iPhone=