[14317] in bugtraq
Re: Our old friend Firewall-1
daemon@ATHENA.MIT.EDU (Hugo.van.der.Kooij@CAIW.NL)
Fri Mar 17 00:17:28 2000
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.LNX.4.10.10003150744460.5683-100000@bastion.hugo.vanderkooij.org>
Date: Wed, 15 Mar 2000 07:46:30 +0100
Reply-To: Hugo.van.der.Kooij@CAIW.NL
From: Hugo.van.der.Kooij@CAIW.NL
X-To: Chris Brenton <cbrenton@sover.net>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <38CB00EB.A9F776F7@sover.net>
On Sat, 11 Mar 2000, Chris Brenton wrote:
>
> The Dartmouth Collage security group has uncovered a problem with
> Firewall-1 which could lead to the protected site handing out more IP
> address info than intended.
>
> Under certain nominal load conditions (CPU less than 40%, 200+ active
> sessions) Firewall-1 will begin "leaking" packets with their private
> address information in tact. The result is that the receiving site will
> receive a SYN=1 that it will be unable to respond to. Once the client
> attempts a resend, the target network (or anyone in the middle) can use
> the source port information to enumerate the client's true IP address.
>
> Here is a Snort trace which has been sanitized and formatted for easier
> viewing:
> Mar 9 14:01:19 172.30.1.10:1721 -> 192.168.1.5:80 SYN **S*****
> Mar 9 14:01:48 200.200.200.5:1721 -> 192.168.1.5:80 SYN **S*****
>
> Mar 9 14:04:35 172.30.1.10:1858 -> 192.168.1.5:80 SYN **S*****
> Mar 9 14:05:05 200.200.200.5:1858 -> 192.168.1.5:80 SYN **S*****
>
> Mar 9 14:23:25 172.16.5.20:4868 -> 192.168.1.5:80 SYN **S*****
> Mar 9 14:23:51 200.200.200.5:4868 -> 192.168.1.5:80 SYN **S*****
>
> So the first packet goes out with the private address information still
> in place and SYN=1. When the client does not receive a reply, it
> retransmits the SYN=1. Since FW-1 considers this to be part of the same
> session, the same source port number is assigned. If the second packet
> gets translated properly (as in these traces) the source port info can
> potentially be used to map the legal IP address to the private address.
>
> Of course the problem here is that a would be bad guy now knows the
> client's true IP address. If enough hosts are recorded, its possible
> that most of the internal network address space could be enumerated.
>
> This problem has been noted on Firewall-1 versions 3.0b & 4.0. 4.1 has
> not been checked but its expected that the same problem may exist. We
> where able to reproduce the problem on a Nokia IP440 and NT. I've seen
> this problem on Solaris 2.6 as well, but do not have the data to back up
> the statement.
Please provide exact patchlevels. I know the problem occurs in FireWall-1
v4.0 SP4 but should be fixed in SP5 that is available as of 2000/03/14
Hugo.
--
Hugo van der Kooij; Oranje Nassaustraat 16; 3155 VJ Maasland
hvdkooij@caiw.nl http://home.kabelfoon.nl/~hvdkooij/
--------------------------------------------------------------
Use of any of my email addresses for unsollicited (commercial)
email is a clear intrusion of my privacy and illegal!
