From nobody@FreeBSD.org  Thu Mar 31 23:07:14 2005
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E041916A4CE
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 31 Mar 2005 23:07:14 +0000 (GMT)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A017043D46
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 31 Mar 2005 23:07:14 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id j2VN7EPP074139
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 31 Mar 2005 23:07:14 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id j2VN7EOm074138;
	Thu, 31 Mar 2005 23:07:14 GMT
	(envelope-from nobody)
Message-Id: <200503312307.j2VN7EOm074138@www.freebsd.org>
Date: Thu, 31 Mar 2005 23:07:14 GMT
From: Jonathan Dama <devteam@donut.ugcs.caltech.edu>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ipf in 4.11 breaks POLA
X-Send-Pr-Version: www-2.3

>Number:         79416
>Category:       kern
>Synopsis:       ipf in 4.11 breaks POLA
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    darrenr
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 31 23:10:06 GMT 2005
>Closed-Date:    Sun Feb 19 19:35:49 UTC 2012
>Last-Modified:  Sun Feb 19 19:35:49 UTC 2012
>Originator:     Jonathan Dama
>Release:        4.11-STABLE
>Organization:
ASCIT, inc.
>Environment:
FreeBSD donut.ugcs.caltech.edu 4.11-STABLE FreeBSD 4.11-STABLE #1: Tue Mar 22 00:12:05 PST 2005     root@donut.ugcs.caltech.edu:/usr/obj/usr/src/sys/BEARCLAW  i386

>Description:
ipf's interpretation of icmp rules has changed.  This constitutes a POLA violation.  See kern/73399 for a report of this problem against 5.3 as a regression versus 4.x.  Original PR was closed because a simple rule rewrite resolves the issue.  Some MFC has brought this regression into 4.x.  As 4.x is a STABLE release branch, POLA holds; "simply change your configuration files" is not acceptable solution for stable branches in relationship to components of the base system.

Problem summary:
ipf cites a pass rule as grounds for blocking a packet.  This applies specifically to protocol type icmp and the keep-state directive.

>How-To-Repeat:
Create a rule set such as:
block in all
pass in quick on lo0 from any to any
pass out quick on lo0 from any to any
pass out quick on fxp0 proto tcp from any to any flags S/FSRPAU keep state keep frags
pass out quick on fxp0 proto udp from any to any keep state
pass out quick on fxp0 proto icmp from any to any keep state
pass in  quick on fxp0 proto icmp from trustnet to any

This results in the following activity:
31/03/2005 01:36:37.333242 fxp0 @0:3 p trustedip -> localip PR icmp len 20 84 icmp echo/0 IN
31/03/2005 01:36:37.333259 fxp0 @0:4 B localip -> trustedip PR icmp 

rule #4, "pass out quick on fxp0 proto icmp from any to any keep state" is cited as cause to block the reply packet.

1) This is textual nonsense.  A pass-rule should never be cited as cause for dropping a packet.
2) This is behavioral change in 4.11-STABLE relative to earler 4.x releases, as such it constitutes a POLA violation. 

The echo reply should have matched rule #4 and been passed.

>Fix:
Only the original hack given by pr/73399, replace the keep-state icmp pass-rule with pass out quick on fxp0 proto icmp
>Release-Note:
>Audit-Trail:

From: Spartak Radchenko <spartak@aif.ru>
To: freebsd-gnats-submit@FreeBSD.org, devteam@donut.ugcs.caltech.edu
Cc:  
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Fri, 08 Apr 2005 21:58:19 +0400

 The same applies to tcp rules.
 This ruleset worked OK in 4.8, 4.9, 4.10 (all outbound tcp connections, 
 incoming connections on port 80):
 
 block in log all
 pass in quick proto tcp from any to any port = 80
 pass out proto tcp from any to any keep state
 
 Yes, I know that such ruleset is not recommended in ipfilter how-to, but 
 it worked anyway.
 And I think that "not recommended" doesn't mean "strictly prohibited".
 In 4.11 incoming connections to port 80 do not work any more. The 
 ruleset must be modified:
 
 block in log all
 pass in quick proto tcp from any to any port = 80
 pass out quick proto tcp from any port = 80  to any
 pass out  proto tcp from any to any keep state
 
 --
 Spartak Radchenko SVR1-RIPE

From: Spartak Radchenko <spartak@aif.ru>
To: freebsd-gnats-submit@FreeBSD.org, devteam@donut.ugcs.caltech.edu
Cc:  
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Fri, 08 Apr 2005 22:14:25 +0400

 BTW, UDP is also affected.
 
 Here is my test ruleset for traceroute:
 
 block in log all
 pass  in quick proto udp from any to any port 33434 >< 33690
 pass out proto icmp from any to any keep state
 
 Host with this ruleset can be tracerouted from outside in 4.8, 4.9. 
 4.10. But not in 4.11. Counter for last rule is incremented for each 
 outbound icmp unreach, however. Is it a bug or not? I am not sure.
 
 And this ruleset works in 4.11:
 
 block in log all
 pass  in quick proto udp from any to any port 33434 >< 33690
 pass out quick proto icmp from any to any icmp-type unreach
 pass out proto icmp from any to any keep state
 
 --
 Spartak Radchenko SVR1-RIPE
Responsible-Changed-From-To: freebsd-bugs->darrenr 
Responsible-Changed-By: kris 
Responsible-Changed-When: Sat Apr 9 00:44:05 GMT 2005 
Responsible-Changed-Why:  
Assign to ipf maintainer 

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

From: Giorgos Keramidas <keramida@freebsd.org>
To: Spartak Radchenko <spartak@aif.ru>, freebsd-bugs@freebsd.org
Cc: bug-followup@freebsd.org
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Sat, 9 Apr 2005 04:02:39 +0300

 On 2005-04-08 18:00, Spartak Radchenko <spartak@aif.ru> wrote:
 > This ruleset worked OK in 4.8, 4.9, 4.10 (all outbound tcp
 > connections, incoming connections on port 80):
 >
 > block in log all
 > pass in quick proto tcp from any to any port = 80
 > pass out proto tcp from any to any keep state
 >
 > Yes, I know that such ruleset is not recommended in ipfilter how-to,
 > but it worked anyway.
 
 The correct way to do the same thing is:
 
     block in log all
     pass in quick proto tcp from any to any port = 80 keep state
     pass out proto tcp from any to any keep state
 
 You're missing a "keep state" in the incoming rule.
 
 > And I think that "not recommended" doesn't mean "strictly prohibited".
 
 IMHO, it does mean "not guaranteed to work" though ;-)
 
 > In 4.11 incoming connections to port 80 do not work any more. The
 > ruleset must be modified:
 >
 > block in log all
 > pass in quick proto tcp from any to any port = 80
 > pass out quick proto tcp from any port = 80  to any
 > pass out  proto tcp from any to any keep state
 
 This is still wrong.

From: Spartak Radchenko <spartak@aif.ru>
To: freebsd-gnats-submit@FreeBSD.org, devteam@donut.ugcs.caltech.edu
Cc:  
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Sat, 09 Apr 2005 12:46:45 +0400

 On Sat, Apr 09, 2005 at 04:02:39AM +0300, Giorgos Keramidas wrote:
 
 > You're missing a "keep state" in the incoming rule.
  
 >> And I think that "not recommended" doesn't mean "strictly prohibited".
  
 > IMHO, it does mean "not guaranteed to work" though ;-)
 
 Does it? Below is a quote from http://www.obfuscation.org/ipf/ipf-howto.txt 
 
 --- cut ---
 Consider the following ruleset:
 
      pass  in  quick on tun0 proto tcp from any to 20.20.20.1/32 port = 23
      pass  out quick on tun0 proto tcp from any to any keep state
      block in  quick all
      block out quick all
 
 At  first  glance,  this seems to be a good setup.  We allow
 incoming sessions to port 23,  and  outgoing  sessions  any-
 where.   Naturally  packets going to port 23 will have reply
 packets, but the ruleset is setup in such  a  way  that  the
 pass  out  rule  will  generate a state entry and everything
 will work perfectly.  At least, you'd think so.
 
      The unfortunate truth is that after 60 seconds of  idle
 time  the state entry will be closed (as opposed to the nor-
 mal 5 days).  This is because the state  tracker  never  saw
 the original SYN packet destined to port 23, it only saw the
 SYN ACK.
 --- cut ---
 
 IMHO, such behaviour is quite acceptable and even desirable. Blocking in 
 pass rule is not.
 
  >> block in log all
  >> pass in quick proto tcp from any to any port = 80
  >> pass out quick proto tcp from any port = 80 to any
  >> pass out proto tcp from any to any keep state
 
 > This is still wrong.
 
 But why? It does exactly what I want. As a rule, I don't like keep state 
 on inbound connections. Especially with 5 days idle timeout ;)

From: devteam@donut.ugcs.caltech.edu
To: Spartak Radchenko <spartak@aif.ru>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Sat, 9 Apr 2005 20:10:55 -0700

 > I know that such ruleset is not recommended in ipfilter how-to, but 
 > it worked anyway. And I think that "not recommended" doesn't mean 
 > "strictly prohibited".  In 4.11 incoming connections to port 80 do 
 > not work any more.
 
 Regardless, it is a POLA violation.
 
 I can understand changing the behavior going from 4.x->5.x,
 but not within the 4-STABLE series.
 
 POLA is one of the best features of FreeBSD.
 

From: Giorgos Keramidas <keramida@freebsd.org>
To: Spartak Radchenko <spartak@aif.ru>, freebsd-bugs@freebsd.org
Cc: bug-followup@freebsd.org
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Sat, 9 Apr 2005 04:02:39 +0300

 On 2005-04-08 18:00, Spartak Radchenko <spartak@aif.ru> wrote:
 > This ruleset worked OK in 4.8, 4.9, 4.10 (all outbound tcp
 > connections, incoming connections on port 80):
 >
 > block in log all
 > pass in quick proto tcp from any to any port = 80
 > pass out proto tcp from any to any keep state
 >
 > Yes, I know that such ruleset is not recommended in ipfilter how-to,
 > but it worked anyway.
 
 The correct way to do the same thing is:
 
     block in log all
     pass in quick proto tcp from any to any port = 80 keep state
     pass out proto tcp from any to any keep state
 
 You're missing a "keep state" in the incoming rule.
 
 > And I think that "not recommended" doesn't mean "strictly prohibited".
 
 IMHO, it does mean "not guaranteed to work" though ;-)
 
 > In 4.11 incoming connections to port 80 do not work any more. The
 > ruleset must be modified:
 >
 > block in log all
 > pass in quick proto tcp from any to any port = 80
 > pass out quick proto tcp from any port = 80  to any
 > pass out  proto tcp from any to any keep state
 
 This is still wrong.
 _______________________________________________
 freebsd-bugs@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
 

From: linimon@lonesome.com (Mark Linimon)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/79416: ipf in 4.11 breaks POLA
Date: Tue, 28 Feb 2006 03:49:22 -0600

 ----- Forwarded message from Darren Reed <darrenr@FreeBSD.org> -----
 
 IPFilter now converts a "pass" rule into a block if, during processing
 the packet, it decides that it has the final matching rule but something
 else happens that means some sort of assumption about the packet being
 passed is bad.
 
 That "something else" might be a NAT proxy decided it wants the packet
 to be dropped or adding state fails with a rule that isn't "quick".
 
 I believe what was happening here is that in earlier versions of ipfilter
 4.1 than 4.1.10, it would see that state couldn't be added (at the end
 of rule processing) and drop the packet - even with "quick" rules.  Now,
 if "keep state" fails for a packet on a "quick" rule, the failure to add
 state becomes a reason to treat the packet as not matching the rule and
 we go to the next filter rule.
 
 In FreeBSD prior to IPFilter 4.x, if state failed to be added then the
 packet would still be allowed through.
 
 What is the difference here?  If the original packet is allowed through,
 say it is a TCP SYN packet and no state is created then a SYN-ACK will
 be received and consequently blocked because there is no state.  This
 can be a bit puzzling and also fails to enforce session limits, like it
 should, without impacting the system "inside."
 
 My real concern with this bug report is that the block ICMP packet
 should have been matched by state and wasn't.  Is that still
 reproducible with FreeBSD-current ?
 
 Darren
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Sun Feb 19 19:34:23 UTC 2012 
State-Changed-Why:  
Unfortunately this PR never got a followup.  It has now been obsoleted 
by the passage of time. 

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