8422348 2002-05-09 20:03 +0200 /55 rader/ Felix von Leitner <felix-bugtraq@fefe.de>
Sänt av: joel@lysator.liu.se
Importerad: 2002-05-11 05:39 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22243>
Ärende: Linux kernel 2.4 "weak end host" issue (previously discussed here as "arp problem")
------------------------------------------------------------
From: Felix von Leitner <felix-bugtraq@fefe.de>
To: bugtraq@securityfocus.com
Message-ID: <20020509180305.GA6048@codeblau.de>
A service bound to the IP of eth1 is still visible from eth0.
This is not an RFC violation (RFC1122 calls this "weak end host"), but
it is unexpected for most Linux users, and the very reason why people
bind a service to the IP of a specific network interface usually is to
make sure it can only be used from that interface (DHCP, samba, squid
and intranet web servers come to mind).
This is not an ARP issue. Making the kernel stop answering to ARP
requests will not make it harder for an attacker to reach the service.
Here is how to reproduce the behaviour:
host a (eth0 connected to eth0 of host b):
ifconfig eth0 10.0.0.1
ifconfig eth1 23.0.0.1
tcpserver -RHl localhost 23.0.0.1 8000 echo fnord
host b:
ifconfig eth0 10.0.0.2
route add 23.0.0.1 gw 10.0.0.1
telnet 23.0.0.1 8000
No ARP request or answer for 23.0.0.1 is involved at all.
tcpserver is from ucspi-tcp, use any other method to quickly bind a
service to 23.0.0.1 at your discretion. This appears not work for
services bound to 127.0.0.1, as this appears to be magically
hard-wired to 127.0.0.1 (setting lo to another IP and setting a
static route did not make a TCP connection appear on eth0 for me).
This means that I could not get telnet on host b to send packets
destined for 127.* out over eth0. That should not hinder attackers
using other operating systems or raw sockets to pull this attack off.
Previously, when this issue was brought up, the canonical answer was
to
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
but this option is no longer available in recent 2.4 kernels.
I put together an experimental patch for 2.4.18 at
http://www.fefe.de/linux-eth-forwarding.diff
Be warned, though, that it may be horribly broken (not tested for SMP
or machines with more than one IP per interfaces). There is a Linux
specific kludge^Whack^Wmethod to bind to an interface, but I am not
aware of any software using it. If you have multi homed hosts and
rely on a service bound to eth1 not being visible to eth0, you need
to use netfilter or this patch!
Felix
(8422348) /Felix von Leitner <felix-bugtraq@fefe.de>/(Ombruten)
Kommentar i text 8424681 av Dax Kelson <dax@gurulabs.com>
8424681 2002-05-11 02:31 -0600 /31 rader/ Dax Kelson <dax@gurulabs.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-05-12 00:44 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com <bugtraq@securityfocus.com>
Extern kopiemottagare: Felix von Leitner <felix-bugtraq@fefe.de>
Mottagare: Bugtraq (import) <22248>
Kommentar till text 8422348 av Felix von Leitner <felix-bugtraq@fefe.de>
Ärende: Re: Linux kernel 2.4 "weak end host" issue (previously discussed here as "arp problem")
------------------------------------------------------------
From: Dax Kelson <dax@gurulabs.com>
To: "bugtraq@securityfocus.com" <bugtraq@securityfocus.com>
Cc: Felix von Leitner <felix-bugtraq@fefe.de>
Message-ID: <Pine.LNX.4.44.0205110221380.17267-100000@mooru.gurulabs.com>
On Thu, 9 May 2002, Felix von Leitner wrote:
> A service bound to the IP of eth1 is still visible from eth0.
> This is not an RFC violation (RFC1122 calls this "weak end host"), but
Linux isn't unique in this regard as Solaris has the same
behavior. You are correct in that although likely surprising, it
isn't a RFC violation.
On Solaris you can turn this behavior off with:
# ndd -set /dev/ip ip_strict_dst_multihoming 1
On Linux, you could use this IP Tables command (eth0 external, and
eth1 internal):
# iptables -A INPUT -i eth0 -d IP_of_eth1 -j DROP
Lastly, I would comment that most likely the internal interface would
be using RFC1918 reserved address space, so an attacker 'out on the
net' somewhere wouldn't be able to route packets to the potential
vicitim's internal IP address.
Dax Kelson
Guru Labs
(8424681) /Dax Kelson <dax@gurulabs.com>/-(Ombruten)
8438878 2002-05-14 09:47 -0500 /74 rader/ Matthew G. Marsh <mgm@paktronix.com>
Sänt av: joel@lysator.liu.se
Importerad: 2002-05-14 17:54 av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <22267>
Kommentar till text 8422348 av Felix von Leitner <felix-bugtraq@fefe.de>
Ärende: Re: Linux kernel 2.4 "weak end host" issue Explained
------------------------------------------------------------
From: "Matthew G. Marsh" <mgm@paktronix.com>
To: bugtraq@securityfocus.com
Message-ID: <Pine.LNX.4.43.0205140929290.17955-100000@netmonster.pakint.net>
Note to Moderator: I can provide a more detailed explanation for the
commands cited below but feel it may not be of interest to the broader
public. If you would prefer.
-----
On Thu, 9 May 2002, Felix von Leitner wrote:
> A service bound to the IP of eth1 is still visible from eth0.
> This is not an RFC violation (RFC1122 calls this "weak end host"), but
> it is unexpected for most Linux users, and the very reason why people
> bind a service to the IP of a specific network interface usually is to
> make sure it can only be used from that interface (DHCP, samba, squid
> and intranet web servers come to mind).
Any Linux users who think this way are sadly misinformed as to how
IPv4 works in general. This is expected and normal behaviour for
Linux. Stating otherwise reveals a deep disregard for the variety of
structure and definition of IPv4 and an assumption that there is only
one true way. Bluntly put - the world is not BSD nor is it
Microsoft. Read the RFCs and learn how IPv4 works.
IP adresses have nothing to do with physical interfaces. An IP
address (or indeeed any generalized location structure name) defines
the contact point for a service. All references to binding exist due
to this fundamental fact of addressing. That is why ARP exists in the
first place. ARP is a protocol to allow communication over Layer 2
(DataLink) to occur as required (think raw ethernet/token ring)
between a Service and Requestor.
> This is not an ARP issue. Making the kernel stop answering to ARP
> requests will not make it harder for an attacker to reach the service.
Correct. [snip]
> There is a Linux
> specific kludge^Whack^Wmethod to bind to an interface, but I am not
> aware of any software using it. If you have multi homed hosts and rely
> on a service bound to eth1 not being visible to eth0, you need to use
> netfilter or this patch!
No. Due to the unparalleled scope and breadth of Linux IPv4
networking you simply can change the behaviour through
routing. Example:
eth0 = 1.1.1.1/24
eth1 = 2.2.2.2/24
ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000
ip route add default dev eth0 table 1
ip route add default dev eth1 table 2
If anyone would like more detailed explanations of this subject
please feel free to email me. Linux IPv4 routing contains a wealth of
power under the hood.
> Felix
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250 x101
Email: mgm@paktronix.com
WWW: http://www.paktronix.com
--------------------------------------------------
(8438878) /Matthew G. Marsh <mgm@paktronix.com>/(Ombruten)