From nobody@FreeBSD.ORG  Wed Jun 28 16:55:38 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 5059D37C2F1; Wed, 28 Jun 2000 16:55:38 -0700 (PDT)
Message-Id: <20000628235538.5059D37C2F1@hub.freebsd.org>
Date: Wed, 28 Jun 2000 16:55:38 -0700 (PDT)
From: kevin@telco21.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: stock IPFW rules have subtle udp hole
X-Send-Pr-Version: www-1.0

>Number:         19569
>Category:       conf
>Synopsis:       stock IPFW rules have subtle udp hole
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 28 17:00:01 PDT 2000
>Closed-Date:    Mon Jul 23 09:47:18 PDT 2001
>Last-Modified:  Mon Jul 23 09:47:59 PDT 2001
>Originator:     Kevin Glavin
>Release:        3.X, 4.X - probably 2.x also
>Organization:
>Environment:
FreeBSD pod 4.0-RELEASE FreeBSD 4.0-RELEASE #0: Sat Jun 24 16:55:34 GMT 2000     root@pod:/u2/usr/src/sys/compile/pod  i386
>Description:
ipfw stock rules have loosely defined rules for udp port 53 and the ntp port 
(123 I think). the rules are defined in such a fashion that once a packet is
coming from (internet anywhere) port 53 to any port (on for example your outside
 interface) 'you' assume its a DNS lookup response or once a udp packet is going 
out to port 53 from any port on your outside interface 'you' assume its a dns query. 

This assumption, allows me to write a port scanner that binds as port 53 on the 
scanning machine and scan all udp ports on FreeBSD machines that use these rules to 
allow DNS/NTP but are assuming that they have blocked all other UDP access
So if I am running another udp based service that I thought was protected 
by a ipfw rules on the outside interface it may actually be wide open once the attacking 
client bound to port 53 to initiate contact with the service.
>How-To-Repeat:

as part of stock install, compile kernel to use IPFW with the
'simple' rules enabled to nat an internal 192.168.X network of home PC's 
>Fix:

Fix that works on certain configurations is to tightly specify 
the rules as 

 # Allow DNS queries out in the world : note query port set to 53 in named
.conf
    $fwcmd add pass udp from any 53 to ${oip} 53
    $fwcmd add pass udp from ${oip} 53  to any 53
## now internet based clients bound to port 53 can only connect to named
## instead of having free reign. 

#same thing for NTP
 # Allow NTP queries out in the world
    $fwcmd add pass udp from any 123 to ${oip} 123
    $fwcmd add pass udp from ${oip} 123 to any 123



>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: mike 
State-Changed-When: Sat Jul 21 21:43:21 PDT 2001 
State-Changed-Why:  

Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE? 

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

From: Mike Barcroft <mike@FreeBSD.org>
To: Kevin Glavin <kevin@shenick.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: conf/19569: stock IPFW rules have subtle udp hole
Date: Mon, 23 Jul 2001 01:04:50 -0400

 On Sun, Jul 22, 2001 at 08:02:13PM -0700, Kevin Glavin wrote:
 > 
 > 4.3-Stable has a dynamic rule which keeps state which 
 > I assume fixes it on the outbound  direction, 
 > not sure if its in 4.3-Release or not
 > 
 > Bug still exists in 4.2-Release, not sure about 4.2-Stable
 
 There is only one -STABLE branch.  Releases are simply snapshots
 of the -STABLE branch at any given time.  Anyway, are you
 satisfied this bug has been resolved in 4.3-STABLE?
 
 Best regards,
 Mike Barcroft
State-Changed-From-To: feedback->closed 
State-Changed-By: mike 
State-Changed-When: Mon Jul 23 09:47:18 PDT 2001 
State-Changed-Why:  

Originator believes this problem has been solved in 4.3-STABLE. 

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