Re: Loopback and multi-homed routing flaw in TCP/IP stack.

[Perry Harrington <pedward () WEBCOM COM>]

I understand the severity of the situation.  Basically you are pointing
out that people binding services to 'local' interfaces are being fooled
into a false sense of security through obscurity.

Yeah, it's dumb to not use a firewall on your box.

What you describe as a 'flaw' is actually caused by one issue (in linux
at least), and is exploited by commercial vendors.

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.

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.

In short, yes security through obscurity is dumb, but calling for people to change
this functionality is unwarranted when machines can be firewalled.

--Perry

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.
>
> 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). This means that
> connections can be made to services that were intended to be invisible
> by virtue of the fact that they were only listening on the "inside" of
> a system. This may lead to further compromise of the host and/or
> connected networks, either via (e.g.) buffer overflows or enhanced
> privileges via access to SOCKS or other internal proxies.
>
> Acknowledgments:
>
>   Woody       <woody () thebunker net>
>   Adam Laurie <adam () algroup co uk>
>   Ben Laurie  <ben () algroup co uk>
>   Doug Lang   <doug () thebunker net>
>   http://www.thebunker.net

--
Perry Harrington                 Director of                   zelur xuniL  ()
perry at webcom dot com      System Architecture               Think Blue.  /\

Attachment: _bin
Description: