Bug 19569

Summary: stock IPFW rules have subtle udp hole
Product: Base System Reporter: kevin <kevin>
Component: confAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description kevin 2000-06-29 01:00:01 UTC
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.

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
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
Comment 1 Mike Barcroft freebsd_committer freebsd_triage 2001-07-22 05:43:21 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-23 06:04:50 UTC
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
Comment 3 Mike Barcroft freebsd_committer freebsd_triage 2001-07-23 17:47:18 UTC
State Changed
From-To: feedback->closed


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