NetBSD Problem Report #9137

Received: (qmail 3102 invoked from network); 6 Jan 2000 23:58:17 -0000
Message-Id: <200001062357.IAA00493@itojun.org>
Date: Fri, 7 Jan 2000 08:57:39 +0900 (JST)
From: Jun-ichiro itojun Hagino <itojun@itojun.org>
Reply-To: itojun@itojun.org
To: gnats-bugs@gnats.netbsd.org
Subject: udp and spec issues
X-Send-Pr-Version: 3.95

>Number:         9137
>Category:       kern
>Synopsis:       udp and spec issues
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 06 16:00:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Sat Nov 17 13:34:59 +0000 2007
>Originator:     Jun-ichiro itojun Hagino
>Release:        1.4.1
>Organization:
	itojun.org
>Environment:
System: NetBSD lychee.itojun.org 1.4.1 NetBSD 1.4.1 (LYCHEE.v6) #487: Fri Jan 7 08:45:58 JST 2000 itojun@lychee.itojun.org:/export/home/itojun/k/kame/netbsd/sys/arch/i386/compile/LYCHEE.v6 i386

	also applicable to -current

>Description:
	udp_usrreq.c disagrees with RFC768 in the following issues:
	- there's no way to transmit UDP packet with src port == 0
	  (it is legal)
	- input routine accepts dst port == 0 (it looks illegal).
	  any udp socket would accept dst port == 0 packet, after socket() and
	  before the first bind()/connect().

	attacker can use the latter to confuse, or de-synchronize udp-based
	protocol exchange.

	Not sure if it is real problem or not, but the code and spec
	seem inconsistent.
>How-To-Repeat:
>Fix:
	the former one does not really harm us.
	latter one is more critical, and more trivial to fix.

Index: netbsd/sys/netinet/udp_usrreq.c
===================================================================
RCS file: /cvsroot/kame/kame/netbsd/sys/netinet/udp_usrreq.c,v
retrieving revision 1.26
diff -c -r1.26 udp_usrreq.c
*** netbsd/sys/netinet/udp_usrreq.c	2000/01/06 06:37:47	1.26
--- netbsd/sys/netinet/udp_usrreq.c	2000/01/07 18:09:31
***************
*** 218,223 ****
--- 218,227 ----
  	}
  #endif

+ 	/* destination port of 0 is illegal, based on RFC768. */
+ 	if (uh->uh_dport == 0)
+ 		goto bad;
+ 
  	/*
  	 * Make mbuf data length reflect UDP length.
  	 * If not enough data to reflect UDP length, drop.
***************
*** 375,380 ****
--- 379,388 ----
  		goto bad;
  	}

+ 	/* destination port of 0 is illegal, based on RFC768. */
+ 	if (uh->uh_dport == 0)
+ 		goto bad;
+ 
  	/* Be proactive about malicious use of IPv4 mapped address */
  	if (IN6_IS_ADDR_V4MAPPED(&ip6->ip6_src) ||
  	    IN6_IS_ADDR_V4MAPPED(&ip6->ip6_dst)) {
***************
*** 925,930 ****
--- 933,942 ----
  		ip = mtod(m, struct ip *);
  	}
  	uh = (struct udphdr *)((caddr_t)ip + iphlen);
+ 
+ 	/* destination port of 0 is illegal, based on RFC768. */
+ 	if (uh->uh_dport == 0)
+ 		goto bad;

  	/*
  	 * Make mbuf data length reflect UDP length.
Index: kame/sys/netinet6/udp6_usrreq.c
===================================================================
RCS file: /cvsroot/kame/kame/kame/sys/netinet6/udp6_usrreq.c,v
retrieving revision 1.29
diff -c -r1.29 udp6_usrreq.c
*** kame/sys/netinet6/udp6_usrreq.c	2000/01/04 11:24:30	1.29
--- kame/sys/netinet6/udp6_usrreq.c	2000/01/07 18:09:33
***************
*** 199,204 ****
--- 199,208 ----
  		goto bad;
  	}

+ 	/* destination port of 0 is illegal, based on RFC768. */
+ 	if (uh->uh_dport == 0)
+ 		goto bad;
+ 
  	/* Be proactive about malicious use of IPv4 mapped address */
  	if (IN6_IS_ADDR_V4MAPPED(&ip6->ip6_src) ||
  	    IN6_IS_ADDR_V4MAPPED(&ip6->ip6_dst)) {
>Release-Note:
>Audit-Trail:

Date: Fri, 14 Jan 2000 08:34:15 -0800
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
Subject: net/9137

	committed change for inbound side (check dst port == 0).
	outbound side is yet to be done.

itojun

State-Changed-From-To: open->analyzed 
State-Changed-By: fair 
State-Changed-When: Thu Jan 20 00:05:03 PST 2000 
State-Changed-Why:  
It looks like Jun-ichiro is taking care of this PR. 


Responsible-Changed-From-To: kern-bug-people->itojun 
Responsible-Changed-By: fair 
Responsible-Changed-When: Thu Jan 20 00:05:03 PST 2000 
Responsible-Changed-Why:  
It looks like Jun-ichiro is taking care of this PR. 
Responsible-Changed-From-To: itojun->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Sat, 17 Nov 2007 13:34:59 +0000
Responsible-Changed-Why:
Back to role account.


>Unformatted:

Home	PR Database Search