From nobody@FreeBSD.ORG Tue Jun  8 20:43:26 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id A3A6315207; Tue,  8 Jun 1999 20:43:26 -0700 (PDT)
Message-Id: <19990609034326.A3A6315207@hub.freebsd.org>
Date: Tue,  8 Jun 1999 20:43:26 -0700 (PDT)
From: eddart@ca.sandia.gov
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: syslog packets from a remote machine are not accepted unless the address is specified as xxx.xxx.xxx.xxx/32 -- shorter masks (including defaults) cause packets to be dropped by syslogd.
X-Send-Pr-Version: www-1.0

>Number:         12091
>Category:       bin
>Synopsis:       syslog packets from a remote machine are not accepted unless the address is specified as xxx.xxx.xxx.xxx/32 -- shorter masks (including defaults) cause packets to be dropped by syslogd.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    nectar
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun  8 20:50:01 PDT 1999
>Closed-Date:    Sat Jul 21 09:39:22 PDT 2001
>Last-Modified:  Sat Jul 21 09:40:03 PDT 2001
>Originator:     Eli Dart
>Release:        3.2-RELEASE
>Organization:
Sandia National Labs
>Environment:
FreeBSD <hostname> 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Tue May 18 04:05:08 GMT 1999     jkh@cathair:/usr/src/sys/compile/GENERIC  i386
>Description:
This problem shows up when attempting accept syslog packets from a
remote machine.  If syslogd is run "syslogd -a 1.2.3.4/24" (the network
is a class C network, netmask 255.255.255.0) syslog packets are dropped.
I have also tried this on a /27 network -- same behavior.

>How-To-Repeat:
Running "syslogd -d -a 1.2.3.4/24" gives the following output:

allowaddr: rule 0: numeric, addr = 1.2.3.4, mask = 255.255.255.0; port = 514
off & running....
init
...
[snip]
...
cvthname(1.2.3.4)
validate: dgram from IP 1.2.3.4, port 514, name <hostname>;
rejected in rule 0 due to IP mismatch.

So, it prints out that it got a udp packet from 1.2.3.4 and dropped it.

In syslogd.c, line 1770, function validate() starts.  In validate(),
line 1793, we walk the list of allowed peers in a for loop.  In that
for loop, line 1800, is the comparison that is causing the problem.
The source address of the udp packet is bitwise anded with the stored
netmask (converted from the /24 on the command line) and compared with
the stored address (gotten from the command line).  Of course these are
different -- the netmask (in net byte order) is 0x00ffffff.  We simply
nuke the first 2 bytes of the incoming packet's address.
>Fix:
Option 1:  always use a 32-bit mask

Option 2: replace this code (in syslogd.c):
   1799                 if (ap->isnumeric) {
   1800                         if ((sin->sin_addr.s_addr & ap->a_mask.s_addr)
   1801                             != ap->a_addr.s_addr) {
   1802                                 dprintf("rejected in rule %d due to IP mismatch.\n", i);
   1803                                 continue;
   1804                         }
   1805                 } else {

With this code:

                if (ap->isnumeric) {
                        if ((sin->sin_addr.s_addr & ap->a_mask.s_addr)
                            != (ap->a_addr.s_addr & ap->a_mask.s_addr) ) {
                                dprintf("rejected in rule %d due to IP mismatch.\n", i);
                                continue;
                        }
                } else {

Hmmm....it says not to submit code.  Oops...  If this comes out garbled,
let me know, and I will mail it to you.  There isn't *much* code...


>Release-Note:
>Audit-Trail:

From: Bill Fenner <fenner@research.att.com>
To: eddart@ca.sandia.gov
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: bin/12091: syslog packets from a remote machine are not accepted unless the address is specified as xxx.xxx.xxx.xxx/32 -- shorter masks (including defaults) cause packets to be dropped by syslogd.
Date: Tue, 8 Jun 1999 22:19:22 -0700

 Isn't the fix to simply use -a 1.2.3.0/24 on the command line?
 
   Bill
 

From: adrian@freebsd.org
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/12091
Date: Tue, 10 Aug 1999 21:13:37 +0800

 There's a couple things you can do: Either be nice and give them a warning,
 or tell them they've messed up.
 
 I've done the former, and the submitted patch does the following:
 
 $ ./syslogd -a 1.1.1.1/24
 Warning! IP '1.1.1.1' is not a valid network address to match
          subnet '255.255.255.0'. Changing to '1.1.1.0'.
 
 The logic is easy enough, from the code:
 
         /*
          * next, validate that the address is a valid network address
          * with the given netmask. You do this by ANDing the address
          * they've given us with the netmask, and if the result is the
          * same, you're clear, otherwise, print a warning. The reason
          * for this is that later on during the matching code, if someon
          * puts in 1.2.3.4/24 in instead of 1.2.3.0/24, it'll never be
          * matched (PR bin/12091)
          */
 
 If anyone thinks this should change to give them an error, tell me.
 
 Patch: 
 
 http://www.freebsd.org/~adrian/syslogd.diff
 
 
 Adrian
 
 

From: Jacques Vidrine <n@nectar.com>
To: freebsd-gnats-submit@freebsd.org
Cc: adrian@freebsd.org
Subject: Re: bin/12091 syslog packets from a remote machine are not
 accepted unless the address is specified as xxx.xxx.xxx.xxx/32 -- shorter
 masks (including defaults) cause packets to be dropped by syslogd.
Date: Tue, 05 Oct 1999 23:22:38 -0500

 The right thing to do is to DTRT (fix the address/mask pair) and give
 them a warning.  I would use a warning message such as:
 
 $ syslogd -a 1.1.1.1/24
 WARNING: matching 1.1.1.0/24, I hope this is what you wanted.
 
 There's nothing intrinsically _wrong_ with specifying something such
 as 1.1.1.1/24, and it can be handy when cutting & pasting (I want to
 accept anything from the network THAT machine is on).  To me this
 is a bug in the packet matching code, because  1.1.1.1 & 255.255.255.0 = 
 1.1.1.0.
 
 Jacques Vidrine / n@nectar.com / nectar@FreeBSD.org
 
Responsible-Changed-From-To: freebsd-bugs->nectar 
Responsible-Changed-By: mike 
Responsible-Changed-When: Fri Jul 20 15:36:14 PDT 2001 
Responsible-Changed-Why:  

Jacques Vidrine <nectar@FreeBSD.org> seems to have a good grasp of 
the problem and solution.  I'll pass this on to him.  Jacques, if you 
can't do anything with this PR, feel free to send it back to 
freebsd-bugs. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=12091 
State-Changed-From-To: open->feedback 
State-Changed-By: roam 
State-Changed-When: Sat Jul 21 08:41:06 PDT 2001 
State-Changed-Why:  
Crist J. Clark (cjc@FreeBSD.org) claims that he has fixed this 
problem in syslogd.c rev. 1.79 in -current, and rev. 1.59.2.8 
in 4.3-STABLE.  Can you (the submitter, Eli Dart) check if Crist's 
changes did really solve your problem? 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=12091 
State-Changed-From-To: feedback->closed 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 09:39:22 PDT 2001 
State-Changed-Why:  

cjc confirmed this bug has been fixed in -CURRENT and -STABLE. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=12091 
>Unformatted:
