From nobody@FreeBSD.org  Sat Feb 16 20:26:13 2002
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id 5829D37B402
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 16 Feb 2002 20:26:12 -0800 (PST)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.6/8.11.6) id g1H4QCl30503;
	Sat, 16 Feb 2002 20:26:12 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200202170426.g1H4QCl30503@freefall.freebsd.org>
Date: Sat, 16 Feb 2002 20:26:12 -0800 (PST)
From: Igor M Podlesny <poige@morning.ru>
To: freebsd-gnats-submit@FreeBSD.org
Subject: network  broadcast  addresses  may be used for communications with the system just as well as if it was her own.
X-Send-Pr-Version: www-1.0

>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:    cjc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Feb 16 20:30:01 PST 2002
>Closed-Date:    Mon Mar 4 11:18:10 PST 2002
>Last-Modified:  Sun Oct 27 01:30:00 UTC 2013
>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:

From: "Crist J. Clark" <cjc@FreeBSD.ORG>
To: Igor M Podlesny <poige@morning.ru>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: misc/35022: network  broadcast  addresses  may be used for communications with the system just as well as if it was her own.
Date: Sun, 17 Feb 2002 00:43:14 -0800

 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

From: Igor M Podlesny <poige@morning.ru>
To: "Crist J. Clark" <cjc@FreeBSD.ORG>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re[2]: misc/35022: network  broadcast  addresses  may be used for communications with the system just as well as if it was her own.
Date: Sun, 17 Feb 2002 15:51:23 +0700

 > 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 
 

From: "Crist J. Clark" <crist.clark@attbi.com>
To: Igor M Podlesny <poige@morning.ru>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: misc/35022: network  broadcast  addresses  may be used for communications with the system just as well as if it was her own.
Date: Sun, 17 Feb 2002 01:14:58 -0800

 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 
State-Changed-By: cjc 
State-Changed-When: Tue Feb 26 02:31:17 PST 2002 
State-Changed-Why:  
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 
Responsible-Changed-By: cjc 
Responsible-Changed-When: Tue Feb 26 02:31:17 PST 2002 
Responsible-Changed-Why:  
I'll handle the merges. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=35022 
State-Changed-From-To: analyzed->closed 
State-Changed-By: cjc 
State-Changed-When: Mon Mar 4 11:18:10 PST 2002 
State-Changed-Why:  
Fixed in -CURRENT and -STABLE. After further review of the threat, 
this will not be merged into the security-fix branches. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=35022 

From: Thierry Ratouchniak <tratouchniak@me.com>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>,
 "poige@morning.ru" <poige@morning.ru>
Cc:  
Subject: Re: misc/35022: network  broadcast  addresses  may be used for
 communications with the system just as well as if it was her own.
Date: Sun, 27 Oct 2013 02:23:45 +0200

 Envoy=C3=A9 de mon iPhone=
>Unformatted:
