Date: Sat, 16 Feb 2002 20:26:12 -0800 (PST) From: Igor M Podlesny <poige@morning.ru> To: freebsd-gnats-submit@FreeBSD.org Subject: misc/35022: network broadcast addresses may be used for communications with the system just as well as if it was her own. Message-ID: <200202170426.g1H4QCl30503@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 35022 >Category: misc >Synopsis: network broadcast addresses may be used for communications with the system just as well as if it was her own. >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Feb 16 20:30:01 PST 2002 >Closed-Date: >Last-Modified: >Originator: Igor M Podlesny >Release: 4.5-STABLE 4.5-PRERELEASE and 4.4 >Organization: Morning Network Ltd >Environment: it ranges from 4.4 up to 4.5 and have not too much sense at all... >Description: 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. >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. >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----------- --- 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) /* * 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). >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202170426.g1H4QCl30503>