Re: Bugtraq PF vuln issue

[Henning Brauer <lists-openbsd_(_at_)_bsws_(_dot_)_de>]

On Mon, Jul 07, 2003 at 11:28:37PM +0100, Nick Besant wrote:
> I've been watching both tech and misc since this came out but haven't seen any discussion;  looking at this I felt this could be due to bad configuration, but I'm  not too sure how real the problem is.  Does anyone have any thoughts/flames/ideas on this ?
>  
> http://www.securityfocus.com/archive/1/327512/2003-07-01/2003-07-07/0
>  
> The article concerns an apparent vulnerability in PF's rdr handling.

oh this one... we got notice before, I consider that pretty boring.
look:
<q>
Risk
        low
</q>

actually, I'd s/low/nonexistant/ ...

<q>
Overview
        Depending on the scenario an attacker could
        discover the private IP and/or port number where
        packets are redirected to by PF.
</q>

first question: what exactly does the "atacker" gain from knowing the 
internal IP address... ? pretty much nothing.

then, there are invalid prerequisites. packets with source or target 
RFC1918 addresses should never ever enter your network; in any even 
close-to-reasonable setup they are already filtered out on the border 
routers.

even if not, due to the lack of routes to RFC1918 on bgp full mesh 
routers, the "attacker" needs to be very very very close to the 
"attacked" pf box - in nearly every real-world setup, directly 
connected. every intermediate box would need to route the RFC1918 
addresses in question to _your_ box! how realistic!

this list can be continued quite a bit more...

so even if an "attacker" might find out the internal IP address of the 
system pf rdrs to in a very constructed environment, the impact is 
basically zero.

and still, there are multiple ways to work around that.

1) block outgoing packets with src addresses not in the acceptable 
range. that should be standard practice.
example: one external IP, 10/8 inside. thus all NAT.
  block out quick inet on $ext_if from ! $ext_if

if you have multiple external IPs you might need to use a table or 
only do spoof protection filters on the external interface and policy 
on the inner one(s) (that's what I'm doing here), tho the latter might 
conflict with NAT a bit. anyway, table works always.

2) (-current) use tags instead of passing based on the translated 
IP/port.
  rdr on $ext_if proto tcp from any to $ext_if port 80 -> 10.0.0.1 port 8080
  pass in on $ext_if proto tcp from any to 10.0.0.1 port 8080 keep state
becomes
  rdr on $ext_if proto tcp from any to $ext_if port 80 tag redirected \
    -> 10.0.0.1 port 8080
  pass in on $ext_if tagged redirected keep state

3) (-current) use rdr pass.
  rdr pass on $ext_if proto tcp from any to $ext_if port 80 -> 10.0.0.1 port 8080

I find it a bit surprising and even, well, annoying that such stuff 
makes bugtraq nowadays...
  
-- 
http://2suck.net/hhwl.html - http://www.bsws.de/
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)