Bugtraq mailing list archives
Re: Our old friend Firewall-1
From: Hugo.van.der.Kooij () CAIW NL (Hugo.van.der.Kooij () CAIW NL)
Date: Wed, 15 Mar 2000 07:46:30 +0100
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!
Current thread:
- TESO advisory -- wmcdplay krahmer () CS UNI-POTSDAM DE (Mar 11)
- Our old friend Firewall-1 Chris Brenton (Mar 11)
- Re: Our old friend Firewall-1 Hugo.van.der.Kooij () CAIW NL (Mar 14)
- Re: Our old friend Firewall-1 Chris Brenton (Mar 15)
- TESO & C-Skills development advisory -- imwheel Sebastian (Mar 16)
- Re: TESO & C-Skills development advisory -- imwheel WHiTe VaMPiRe (Mar 19)
- Re: Our old friend Firewall-1 Hugo.van.der.Kooij () CAIW NL (Mar 14)
- Re: TESO advisory -- wmcdplay Kris Kennaway (Mar 11)
- CSS Exploits + RDS (IE5) Shane Hird (Mar 12)
- Advisory Update: ServerIron TCP/IP predictability fixed Andrew van der Stock (Mar 12)
- Exploit for Mandrake 6.1 (PAM/userhelper bug) Paulo Ribeiro (Mar 14)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Darron Froese (Mar 17)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Matt Davis (Mar 17)
- Re: Exploit for Mandrake 6.1 (PAM/userhelper bug) Jeremy Gault (Mar 21)
- Exploit for Mandrake 6.1 (PAM/userhelper bug) Paulo Ribeiro (Mar 14)
(Thread continues...)
- Our old friend Firewall-1 Chris Brenton (Mar 11)