[11229] in bugtraq
Re: NT DoS on FW-1 (fwd)
daemon@ATHENA.MIT.EDU (Malikai)
Tue Aug 3 05:07:53 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.05.9908010132130.10632-100000@area51>
Date: Sun, 1 Aug 1999 02:57:48 -0500
Reply-To: Malikai <malikai@INTERACTIVEALIEN.COM>
From: Malikai <malikai@INTERACTIVEALIEN.COM>
X-To: BUGTRAQ <bugtraq@SECURITYFOCUS.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.NEB.4.10.9907301307040.16814-100000@cesium.clock.org>
On Fri, 30 Jul 1999, Matt wrote:
> A FireWall-1 NT denial of service was actually discovered/discussed on
> bugtraq in February using similar methodologies to those described by
> Lance Spitzner in his recent mail. This is one of the public posts,
> but there was quite a bit of discussion in private mail as well.
>
> To summarize: Someone was claiming that this problem was not in
> FireWall-1 NT, but NT's IP stack that was causing the crash. I was fairly
> certain this was not the case, as I had just done quite a bit of testing against NT 4.0
> SP4 at the time with nmap. I had followed up by testing FireWall-1 NT
> v4.1, and it did crash (the NT service shot up to 100% CPU usage) when
> several spoofed SYN scans were run against it's untrusted interface. The
> difference between this attack and the one Lance has described is that
> this attack appeared to work against both the trusted and untrusted
> interfaces, and can be performed over multiple hops.
I am the person who had stated the problem was in NT's stack. The FW1
state tables do not get created when a packet is denied. Also, in the
default config (with a cleanup rule), there are only 9 or so ports open.
If this was FW1 related, it's probably related more to something internal
in NT freaking out and thereby causing FW1 to freak as well.
This problem seems as if it could be fixed by NOT building the state
tables for a connection unless it recieves the SYN/ACK from the
destination host. Just counting a SYN alone is useless, you have no idea
whether or not the connection *can* be established yet. Perhaps to go even
deeper, why not flag that SYN as it's coming in/going outbound with a
timeout value to wait for a SYN/ACK response? If FW1 recieves the SYN/ACK
it's has flagged then it should create the necessary state table.
Otherwise, it should log & discard the flag appropriately.
That would also allow for reasonable connection timeout values (for
connections that we know exist). This could however, have it's drawbacks.
If FW1 does not keep it's state tables when reloading the policy (or
other things), all current connections would be lost. Not too bad
considering we at least know that the connections have been established
and registered with FW1 in a more orderly fashion.
Jason Ihde
