From land@gx.dnepr.net  Thu Apr 24 01:41:52 2003
Return-Path: <land@gx.dnepr.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 04B8E37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 24 Apr 2003 01:41:52 -0700 (PDT)
Received: from gx.dnepr.net (gx.dnepr.net [217.198.131.109])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0DD5C43FD7
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 24 Apr 2003 01:41:51 -0700 (PDT)
	(envelope-from land@gx.dnepr.net)
Received: by gx.dnepr.net (Postfix, from userid 1000)
	id A51A7A8927; Thu, 24 Apr 2003 11:41:46 +0300 (EEST)
Message-Id: <20030424084146.A51A7A8927@gx.dnepr.net>
Date: Thu, 24 Apr 2003 11:41:46 +0300 (EEST)
From: land@dnepr.net
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: ipfw rule 'deny icmp from any to any icmptype 5' matches fragmented icmp packets
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         51341
>Category:       kern
>Synopsis:       [ipfw] [patch] ipfw rule 'deny icmp from any to any icmptype 5' matches fragmented icmp packets
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 24 01:50:13 PDT 2003
>Closed-Date:    
>Last-Modified:  Thu Sep 27 07:43:06 UTC 2012
>Originator:     land@dnepr.net
>Release:        FreeBSD 4.7-RELEASE
>Organization:
>Environment:
System: FreeBSD 4.7-RELEASE i386

>Description:
	IPFW1 rule 'deny icmp from any to any icmptype 5' matches fragmented
	ICMP packets.

>How-To-Repeat:
	ipfw add 1 deny icmp from any to any icmptype 5
	Try to ping external host with big ICMP packets:
	ping -s 2000 host
	
>Fix:


>Release-Note:
>Audit-Trail:

From: Maxim Konovalov <maxim@macomnet.ru>
To: land@dnepr.net
Cc: bug-followup@freebsd.org, luigi@freebsd.org
Subject: Re: kern/51341: ipfw rule 'deny icmp from any to any icmptype 5'
 matches fragmented icmp packets
Date: Thu, 24 Apr 2003 15:14:05 +0400 (MSD)

 Hello,
 
 Could you please test a patch below? Thanks.
 
 Index: sys/netinet/ip_fw.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
 retrieving revision 1.131.2.39
 diff -u -r1.131.2.39 ip_fw.c
 --- sys/netinet/ip_fw.c	20 Jan 2003 02:23:07 -0000	1.131.2.39
 +++ sys/netinet/ip_fw.c	24 Apr 2003 11:12:02 -0000
 @@ -1434,7 +1434,7 @@
  			struct icmp *icmp;
 
  			if (offset != 0)	/* Type isn't valid */
 -				break;
 +				continue;
  			icmp = (struct icmp *) ((u_int32_t *)ip + ip->ip_hl);
  			if (!icmptype_match(icmp, f))
  				continue;
 
 %%%
 
 -- 
 Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org

From: Maxim Konovalov <maxim@macomnet.ru>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/51341: ipfw rule 'deny icmp from any to any icmptype 5'
 matches fragmented icmp packets (fwd)
Date: Thu, 24 Apr 2003 15:43:12 +0400 (MSD)

 Add to audit trail.
 
 -- 
 Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org
 
 ---------- Forwarded message ----------
 Date: Thu, 24 Apr 2003 14:35:58 +0300
 From: Andrey Lakhno <land@dnepr.net>
 To: Maxim Konovalov <maxim@macomnet.ru>
 Subject: Re: kern/51341: ipfw rule 'deny icmp from any to any icmptype 5'
     matches fragmented icmp packets
 
 Hello,
 
 On Thu, 24 Apr 2003, Maxim Konovalov wrote:
 
 > Could you please test a patch below? Thanks.
 
 It works.
 Thank you !
 
 > Index: sys/netinet/ip_fw.c
 > ===================================================================
 > RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
 > retrieving revision 1.131.2.39
 > diff -u -r1.131.2.39 ip_fw.c
 > --- sys/netinet/ip_fw.c	20 Jan 2003 02:23:07 -0000	1.131.2.39
 > +++ sys/netinet/ip_fw.c	24 Apr 2003 11:12:02 -0000
 > @@ -1434,7 +1434,7 @@
 >  			struct icmp *icmp;
 >
 >  			if (offset != 0)	/* Type isn't valid */
 > -				break;
 > +				continue;
 >  			icmp = (struct icmp *) ((u_int32_t *)ip + ip->ip_hl);
 >  			if (!icmptype_match(icmp, f))
 >  				continue;
 >
 > %%%
 
 -- 
 Andrey Lakhno,
 land-ripe
Responsible-Changed-From-To: freebsd-bugs->ipfw 
Responsible-Changed-By: johan 
Responsible-Changed-When: Tue May 6 12:51:20 PDT 2003 
Responsible-Changed-Why:  
Over to maintainer group. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 

From: Maxim Konovalov <maxim@macomnet.ru>
To: Andrey Lakhno <land@dnepr.net>
Cc: bug-followup@freebsd.org, luigi@freebsd.org
Subject: Re: kern/51341
Date: Thu, 3 Jul 2003 18:53:35 +0400 (MSD)

 Hello Andrey,
 
 Here is another workaround: add a following rule before any icmp deny
 rules:
 
 	ipfw add pass icmp from any to any frag
 
 I would like to describe the problem in two words.  Please consider a
 next rule:
 
 	deny icmp from any to any icmptype 5
 
 Consider we get an icmp fragment.  In fact, it does not consist
 information about its type and due to the discussed bug ipfw1 will
 terminate the search and drop it.  ipfw2 behaviour is different: if we
 do not know about icmp type of the packet do not terminate the search
 and check the packet against next rule.
 
 At the moment I really do not want to fix this bug because it changes
 a filtering policy and may have a negative effect to countless
 installations.
 
 Please let me know if you are satisfied with my explanation and I can
 close the PR.
 
 Thanks!
 
 -- 
 Maxim Konovalov, maxim@macomnet.ru, maxim@FreeBSD.org
State-Changed-From-To: open->feedback 
State-Changed-By: maxim 
State-Changed-When: Thu Jul 3 08:24:53 PDT 2003 
State-Changed-Why:  
Feedback awating. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 

From: Maxim Konovalov <maxim@macomnet.ru>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/51341 (fwd)
Date: Fri, 4 Jul 2003 15:09:15 +0400 (MSD)

 ---------- Forwarded message ----------
 Date: Fri, 4 Jul 2003 13:47:56 +0300
 From: Andrey Lakhno <land@dnepr.net>
 To: Maxim Konovalov <maxim@macomnet.ru>
 Subject: Re: kern/51341
 
 Hello,
 
 On Thu, 03 Jul 2003, Maxim Konovalov wrote:
 
 > Here is another workaround: add a following rule before any icmp deny
 > rules:
 >
 > 	ipfw add pass icmp from any to any frag
 >
 > I would like to describe the problem in two words.  Please consider a
 > next rule:
 >
 > 	deny icmp from any to any icmptype 5
 >
 > Consider we get an icmp fragment.  In fact, it does not consist
 > information about its type and due to the discussed bug ipfw1 will
 > terminate the search and drop it.  ipfw2 behaviour is different: if we
 > do not know about icmp type of the packet do not terminate the search
 > and check the packet against next rule.
 >
 > At the moment I really do not want to fix this bug because it changes
 > a filtering policy and may have a negative effect to countless
 > installations.
 >
 > Please let me know if you are satisfied with my explanation and I can
 > close the PR.
 
 I think this bug should be decribed in ipfw(8) or fixed.
 
 -- 
 Andrey Lakhno,
 land-ripe
Responsible-Changed-From-To: freebsd-ipfw->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Sun Nov 26 20:27:46 UTC 2006 
Responsible-Changed-Why:  
grab this; had this ever been fixed? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 
State-Changed-From-To: feedback->suspended 
State-Changed-By: linimon 
State-Changed-When: Sat Mar 1 20:10:45 UTC 2008 
State-Changed-Why:  
Feedback was received some time ago.  It sounds as though this behavior 
should simply be documented? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 
State-Changed-From-To: suspended->closed 
State-Changed-By: maxim 
State-Changed-When: Thu Jul 28 20:29:32 UTC 2011 
State-Changed-Why:  


http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 
State-Changed-From-To: closed->suspended 
State-Changed-By: maxim 
State-Changed-When: Thu Jul 28 20:31:43 UTC 2011 
State-Changed-Why:  
Closed unintentionally.  Restore its state. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 
State-Changed-From-To: suspended->open 
State-Changed-By: remko 
State-Changed-When: Thu Sep 27 07:39:48 UTC 2012 
State-Changed-Why:  
This is likely to be documented, but I will not do this, reassign to the pool 


Responsible-Changed-From-To: remko->freebsd-doc 
Responsible-Changed-By: remko 
Responsible-Changed-When: Thu Sep 27 07:39:48 UTC 2012 
Responsible-Changed-Why:  
Reassign to the pool; this should probably be documented, but I will not do that. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 
>Unformatted:
