Bugtraq mailing list archives
Re: Loopback and multi-homed routing flaw in TCP/IP stack.
From: John Cronin <jsc3 () HAVOC GTF ORG>
Date: Mon, 5 Mar 2001 22:18:16 -0500
--UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline
[snip]
What you describe as a 'flaw' is actually caused by one issue (in linux at least), and is exploited by commercial vendors.
In Solaris with default ip configuration as well, although poster has pointed out that in Solaris you can turn it off.
First, when Linux receives an IP packet on an interface, it runs through the list of valid IP addresses associated with the machine and dumps the packet if it doesn't match and it's not in promiscuous mode. Second, many network hardware vendors use this 'feature' as something called direct service return. It goes like this: a) loadbalancer receives a connection request to port 80 of 128.128.121.15 b) loadbalancer forwards the packet to the inside machine using an internal ARP table that isn't derived from broadcasts. c) inside machine 192.168.1.21 has a loopback interface of 128.128.121.15 d) inside machine accepts connection and replies back to the client with return address of 128.128.121.15 via the 192.168.1.21 ethernet interface. That is called direct service return; the loadbalancer doesn't have to rewrite outgoing packets. This method is used at least by Foundry and Resonate (oldschool resonate was like this) and proably others.
The Linux Virtual Server load balancer (upon which Redhat Piranha, and most likely TurboLinux Cluster, is derived from) also works this way in Direct Routing mode. See http://www.linuxvirtualserver.org for details.
If you simply prefix this advisory as a warning not to rely on internal interfaces, that's fine. But asking vendors to CHANGE the functionality of this would incurr the wrath of EVERY company using loabalancers with DSR.
The Linux Virtual Server folks would also probably be less than pleased. It might be nice if the '-arp' option to ifconfig also worked as documented - right now it is a bit of aggravation to work around having multiple systems try to reply to ARP requests for a shared Virtual IP.
In short, yes security through obscurity is dumb, but calling for people to change this functionality is unwarranted when machines can be firewalled.
And when people rely on the behavior. If you *must* fix this, make it a configuration option, as in Solaris.
On Mon, Mar 05, 2001 at 07:44:43PM +0000, Woody wrote:Subject: Loopback and multi-homed routing flaw in TCP/IP stack. Author: Woody <woody () thebunker net> We believe there to be a serious security flaw in the TCP/IP stack of several Unix-like operating systems. Whilst being "known" behavior on technical mailing lists, we feel that the implications of this "feature" are unexpected. Furthermore, not all platforms behave in the same way, which will obviously lead to invalid expectations. PLEASE NOTE: We have received a lot of replies to this advisory from developers who have missed the point. Before you reply, please read the advisory at least twice, to ensure you understand its implications, and scope.
Maybe the developers are not the ones missing the point - many of them probably understand how this works in great detail - certainly the Linux Virtual Server crowd does.
The Issue: There is a flaw in the TCP/IP stack, such that packets intended for loopback and/or local network interfaces, routed via any other interface, will be delivered EVEN IF THE MACHINE IS CONFIGURED NOT TO BE A GATEWAY (note that in the case of packets destined for the loopback interface, we consider this to be a fault no matter how the host is configured - see RFC 1122 comments below).
What about a virtual IP bound to the loopback interface, or a dummy interface? This is precisely what many load balancing and high availability failover clusters do, as previously mentioned. -- John Cronin mailto: `echo NjsOc3 () SgtPfA orMg | sed 's/[NOSPAM]//g'`
Current thread:
- Loopback and multi-homed routing flaw in TCP/IP stack. Woody (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Elias Levy (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Perry Harrington (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. ddowney (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. John Cronin (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Ben Laurie (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. ddowney (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Perry Harrington (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Ben Laurie (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Perry Harrington (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Ben Laurie (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Dan Harkless (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. MaD dUCK (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. J. Bol (Mar 06)