Date: Wed, 16 Oct 2002 16:58:50 -0400 From: Chuck Swiger <cswiger@mac.com> To: freebsd-security@FreeBSD.ORG Subject: Re: CERT VU#539363 Message-ID: <122BC346-E14A-11D6-BE66-000A27D85A7E@mac.com> In-Reply-To: <20021016124439.T4295-100000@fubar.adept.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, October 16, 2002, at 04:02 PM, Mike Hoskins wrote:
> I'm sure everyone saw this on Bugtraq, firewalls, firewall-wizards, etc..
> .
> But I noticed Apple was quick to resond with a 'we're not vulnerable'
> regarding OS X and wondered if we could draw similar conclusions.
I'm not entirely sure that "not being vulnerable" simply means that OS X's
default configuration doesn't ship with FTP, or whether it means OS X
being used as a firewall (via IPFW, or whatever) isn't vulnerable.
OS X (or FreeBSD, for that matter) may not be vulnerable also because they
don't try to monitor FTP transactions looking for the PASV, and thus don't
create the bogus dynamic rule. Someone using static packet filtering
rules (before a check-state) can block access to the low ports (below 1024)
and mitigate against the spoofed dynamic rules.
> From their "Solution" section:
>
> "Use firewall features that detect and block flood traffic"
>
> I assume they mean things like the PIX can do... Monitor for excessive
> SYNs from foreign hosts and throttle connections (or deny them entirely
> after a threshold). However, if the attacker used randomly forged source
> addresses to an open port on the firewall, I don't see how these features
> would really help.
Syn-flood and ICMP broadcast flood protection in FreeBSD is pretty solid.
I think the vector of the attack is against an FTP server behind a
firewall, not against a port on the firewall itself. Besides, generally
speaking, your firewalls shouldn't have open ports. I live with 22 open
for remote management purposes, but that's it.
> "Use dynamically resizeable state tables"
>
> Couldn't this hurt more at some point? Assuming the attacker has time and
> is able to forge IPs... A state table has to either become full
> (reach net.inet.ip.fw.dyn_max) or use all available resources at some
> point, right? Hard to say which is better.
Sure. Running out of state table entries is perhaps the primary weakness
of dynamic filtering, and it's not clear that there are perfect solutions
to that problem. :-)
> "Use dynamically adjustable session timers (Aggressive Aging)"
>
> Do they mean the net.inet.ip.fw.dyn_* timers? If so, what sort of
> algorithm would do this "dynamic" adjustment, and based upon what
> criterea?
>
> A couple possible cases...
>
> A large number of rules are created for a given host... So the timeout
> values for rules associated with that host are cut short until the total
> rules from that host return below some threshold.
>
> Or maybe a lot of rules are created for a set of hosts causing the state
> table to grow to within some threshold of net.inet.ip.fw.dyn_max, causing
> the lifetime of all rules to be shortened and hopefully create more room
> for additional rules.
I think Luigi Rizzo has already been there; from
/usr/src/sys/netinet/ip_fw.c:
/*
* after reaching 0, dynamic rules are considered still valid for
* an additional grace time, unless there is lack of resources.
*/
static u_int32_t dyn_grace_time = 10 ;
static u_int32_t static_count = 0 ; /* # of static rules */
static u_int32_t dyn_count = 0 ; /* # of dynamic rules */
static u_int32_t dyn_max = 1000 ; /* max # of dynamic rules */
> "Allow connection tracking to be disabled"
>
> I.e. Turn off statefulness? I suppose that could give one time to find a
> real solution, but it may require a lot of work. :)
They probably mean disabling the aspect of the firewall responsible for
examining or proxying passive FTP and adding dynamic rules when it sees a
PASV response.
-Chuck
Chuck Swiger | chuck@codefab.com | All your packets are belong to
us.
-------------+-------------------+-----------------------------------
"The human race's favorite method for being in control of the facts
is to ignore them." -Celia Green
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?122BC346-E14A-11D6-BE66-000A27D85A7E>