bugtraq - RE: ICMP pokes holes in firewalls...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <7C9884991ADAE0479C14F10C858BCDF5122E50@alderaan.smgtec.com>
Date: Thu, 25 Sep 2003 15:05:07 -0700
From: "Daniel Chemko" <dchemko@...tec.com>
To: "H D Moore" <sflist@...italoffense.net>,
	<bugtraq@...kerfactor.com>, <bugtraq@...urityfocus.com>
Subject: RE: ICMP pokes holes in firewalls...

>NAT gateway has been 
>detected as a ignore-the-source UDP forwarder

2.4 kernels: NAT doesn't work without ip_conntrack, and ip_conntrack
always keeps track of source IP addresses (hence its function). I can't
think of a situation for any Linux machine which allows inbound UDP
replies from other sources. Spoofing the original sender's address is a
different story, but that is pandemic of any stateless AND insecure
protocol.

>I posted about this in March of 2000, the kernel development team
response 
>was that many RPC services require this functionality and it would not
be 
>fixed. The reason is that many UDP-based RPC services will respond back

>to requests from an alternative interface using a different IP address 
>entirely.

Just recently someone has written a conntrack handler to traverse
firewalls with RPC as you describe. No leaks to my knowledge, although I
am not too familiar with this module.