6174585 2001-03-05 19:44 +0000 /226 rader/ Woody <woody@THEBUNKER.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-05 22:43 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: woody@THEBUNKER.NET
Mottagare: Bugtraq (import) <15741>
Ärende: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Woody <woody@THEBUNKER.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA3ECAB.EA826D28@thebunker.net>
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.
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
<angelos@keromytis.org> 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 <woody@thebunker.net>
Adam Laurie <adam@algroup.co.uk>
Ben Laurie <ben@algroup.co.uk>
Doug Lang <doug@thebunker.net>
http://www.thebunker.net
(6174585) --------------------------------(Ombruten)
Kommentar i text 6174715 av Elias Levy <aleph1@SECURITYFOCUS.COM>
Kommentar i text 6175409 av Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
Kommentar i text 6175431 av Perry Harrington <pedward@WEBCOM.COM>
Kommentar i text 6175564 av Neil W Rickert <rickert+bt@CS.NIU.EDU>
6175409 2001-03-05 18:03 -0500 /47 rader/ Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 01:45 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ksparger@DIALTONEINTERNET.NET
Mottagare: Bugtraq (import) <15747>
Kommentar till text 6174585 av Woody <woody@THEBUNKER.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.10.10103051704230.25424-100000@kyle>
Woody said:
> Known Not Vulnerable:
> Linux - RH6.2 stock kernel
This information is incorrect; Linux does 'suffer' from this in at
least version 2.2. I believe it also 'suffers' from this in 2.4.
It's easy enough to replicate. For example, on ethernet, just assign
a static MAC address for the IP in question for the server in
question, and you'll get access to the appropriate interface.
Elias Levy said:
> Its obvious that host that implement the Weak ES model are the ones
> vulnerable, while hosts that implement the Strong ES model are not.
I had a similar discussion with the maintainers of the Linux stack a
few months ago. The following quotes (both from Andi Kleen, a listed
maintainer) apply here:
"You're describing the Strong ES model (see 3.3.4.2). Linux 2.2
follows the weak ES model."
"There are already enough mechanisms to enforce a stronger model if
needed: reject routes, firewall rules, routing filter, arpfilter."
-------------------------------------------------------------------------
Ultimately, the 'expected' behaviour depends on how you view the
addresses on the machine -- Are they system wide, or are they
per-interface? -- and therein lies the debate of weak v. strong.
Given that on UNIX-like systems one generally assigns an address to an
interface (via ifconfig), IMO the 'expected' behaviour is that the strong
model is what is implemented. The implication is certainly there.
Thanks,
Kyle Sparger - Senior System Administrator
ksparger@dialtoneinternet.net - http://www.dialtoneinternet.net
Voice - (954) 581-0097 x 122
"Forget college, I'm going pro."
(6175409) --------------------------------(Ombruten)
Kommentar i text 6175578 av MaD dUCK <madduck@MADDUCK.NET>
6175578 2001-03-05 19:50 -0500 /21 rader/ MaD dUCK <madduck@MADDUCK.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 06:40 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: madduck@MADDUCK.NET
Mottagare: Bugtraq (import) <15756>
Kommentar till text 6175409 av Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: MaD dUCK <madduck@MADDUCK.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010305195042.A12028@madduck.net>
also sprach Kyle Sparger (on Mon, 05 Mar 2001 06:03:04PM -0500):
> This information is incorrect; Linux does 'suffer' from this in at least
> version 2.2. I believe it also 'suffers' from this in 2.4. It's easy
> enough to replicate. For example, on ethernet, just assign a static
> MAC address for the IP in question for the server in question, and you'll
> get access to the appropriate interface.
2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems
don't even have a localhost routing entry anymore.
martin
[greetings from the heart of the sun]# echo madduck@!#:1:s@\@@@.net
--
your fly might be open (but don't check it just now).
(6175578) ------------------------------------------
6175431 2001-03-05 15:59 -0800 /82 rader/ Perry Harrington <pedward@WEBCOM.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 02:01 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15748>
Kommentar till text 6174585 av Woody <woody@THEBUNKER.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
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. /\
(6175431) --------------------------------(Ombruten)
Bilaga (application/pgp-signature) i text 6175432
Kommentar i text 6175560 av John Cronin <jsc3@HAVOC.GTF.ORG>
Kommentar i text 6175604 av <ddowney@MAIL.HISLINUXBOX.NET>
Kommentar i text 6175631 av <ddowney@MAIL.HISLINUXBOX.NET>
6175432 2001-03-05 15:59 -0800 /10 rader/ Perry Harrington <pedward@WEBCOM.COM>
Importerad: 2001-03-06 02:01 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15749>
Bilaga (text/plain) till text 6175431
Ärende: Bilaga till: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (SunOS)
Comment: For info see http://www.gnupg.org
iD8DBQE6pCh8fK7Bvd0wfuURAqHkAKCpLBRr7drIVpkJVV2A4FyQYTPaWACdGn2s
tjDaPKjbgNcPFHQIcdczKdM=
=oiPD
-----END PGP SIGNATURE-----
(6175432) ------------------------------------------
6175604 2001-03-05 18:18 -0800 /27 rader/ <ddowney@MAIL.HISLINUXBOX.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 07:05 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ddowney@MAIL.HISLINUXBOX.NET
Mottagare: Bugtraq (import) <15757>
Kommentar till text 6175431 av Perry Harrington <pedward@WEBCOM.COM>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: ddowney@MAIL.HISLINUXBOX.NET
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0103051816170.6928-100000@mail.hislinuxbox.net>
On Mon, 5 Mar 2001, Perry Harrington wrote:
> In short, yes security through obscurity is dumb, but calling for people to change
> this functionality is unwarranted when machines can be firewalled.
>
Actually to me this sounds more like an excuse NOT to fix the problem
simply because it's "industry standard".
Sometimes standards need to be looked at and revamped. In this case
it's one that would affect the industry as a whole. Are you calling
for advisories only simply because the workload would be tremendous
or because you truly believe that fixing this would affect nothing?
---
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation
david.downey@ensim.com
(6175604) --------------------------------(Ombruten)
Kommentar i text 6175624 av Perry Harrington <pedward@WEBCOM.COM>
6175624 2001-03-05 18:43 -0800 /36 rader/ Perry Harrington <pedward@WEBCOM.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 07:27 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15758>
Kommentar till text 6175604 av <ddowney@MAIL.HISLINUXBOX.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
I don't think the behavior should change because of DSR. DSR is more
useful than 'rightness' in my opinion. A switch to turn it off if
you don't want it is something I'd advocate, but the default should
be 'on'.
--Perry
On Mon, Mar 05, 2001 at 06:18:33PM -0800, ddowney@mail.hislinuxbox.net wrote:
> On Mon, 5 Mar 2001, Perry Harrington wrote:
>
> > In short, yes security through obscurity is dumb, but calling for people to change
> > this functionality is unwarranted when machines can be firewalled.
> >
>
>
> Actually to me this sounds more like an excuse NOT to fix the problem
> simply because it's "industry standard".
>
> Sometimes standards need to be looked at and revamped. In this case it's
> one that would affect the industry as a whole. Are you calling for
> advisories only simply because the workload would be tremendous or because
> you truly believe that fixing this would affect nothing?
>
>
> ---
> David D.W. Downey - RHCE
> Consulting Engineer
> Ensim Corporation
> david.downey@ensim.com
>
>
--
Perry Harrington Director of zelur xuniL ()
perry at webcom dot com System Architecture Think Blue. /\
(6175624) --------------------------------(Ombruten)
Bilaga (application/pgp-signature) i text 6175625
6175625 2001-03-05 18:43 -0800 /10 rader/ Perry Harrington <pedward@WEBCOM.COM>
Importerad: 2001-03-06 07:27 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15759>
Bilaga (text/plain) till text 6175624
Ärende: Bilaga till: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (SunOS)
Comment: For info see http://www.gnupg.org
iD8DBQE6pE64fK7Bvd0wfuURAu82AKCPYODPjUjh3oBDgPujYDSvEU/RYgCfbK3o
VWGeGmN3ExAzVrmNi4jR6mo=
=8VsT
-----END PGP SIGNATURE-----
(6175625) ------------------------------------------
6175631 2001-03-05 18:20 -0800 /20 rader/ <ddowney@MAIL.HISLINUXBOX.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 07:33 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ddowney@MAIL.HISLINUXBOX.NET
Mottagare: Bugtraq (import) <15761>
Kommentar till text 6175431 av Perry Harrington <pedward@WEBCOM.COM>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: ddowney@MAIL.HISLINUXBOX.NET
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.21.0103051819230.6946-100000@mail.hislinuxbox.net>
Actually there is one other thought I wanted to state before sending,
so I'll state it now.
Just because a problem can be worked around via some other solution,
in this case a firewall, does not relieve venders from the obligation
to fix something. Sure, they can use the interim solution to buy them
time to actually FIX the problem, but NOT to escape the
responsibility to fix it.
--
David D.W. Downey - RHCE
Consulting Engineer
Ensim Corporation
david.downey@ensim.com
(6175631) --------------------------------(Ombruten)
6175564 2001-03-05 20:07 -0600 /46 rader/ Neil W Rickert <rickert+bt@CS.NIU.EDU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 06:13 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: rickert+bt@CS.NIU.EDU
Mottagare: Bugtraq (import) <15755>
Kommentar till text 6174585 av Woody <woody@THEBUNKER.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Neil W Rickert <rickert+bt@CS.NIU.EDU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <15874.983844424@euclid.cs.niu.edu>
Woody <woody@THEBUNKER.NET> wrote:
>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.
[detailed description snipped]
I am surprised to see this described as a flaw. It is behavior I
have been relying on for some time. Specifically, on my client
machines, I add a route to the alternate interface of my servers via
the direct interface of the same server. This allows direct
connection to the server without relying on a router, regardless of
which IP address is used for the service. For NFS clients, I
consider it important to be able to do this.
If there is a flaw, it is surely in the thinking of people who
mistakenly assumed that multi-homed systems would not behave so as to
allow this.
The original message states
>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.
This is surely an overstatement. I expect that there are many
multi-homed servers which offer the same network services on each
interface. There do not appear to be any security issues in such
cases.
-NWR
(6175564) ------------------------------------------
6179536 2001-03-06 09:09 +0000 /43 rader/ Ben Laurie <ben@ALGROUP.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 18:48 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ben@ALGROUP.CO.UK
Mottagare: Bugtraq (import) <15766>
Kommentar till text 6175564 av Neil W Rickert <rickert+bt@CS.NIU.EDU>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Ben Laurie <ben@ALGROUP.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA4A958.DFF1A599@algroup.co.uk>
Neil W Rickert wrote:
>
> Woody <woody@THEBUNKER.NET> wrote:
>
> >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.
>
> [detailed description snipped]
>
> I am surprised to see this described as a flaw. It is behavior I
> have been relying on for some time. Specifically, on my client
> machines, I add a route to the alternate interface of my servers via
> the direct interface of the same server. This allows direct
> connection to the server without relying on a router, regardless of
> which IP address is used for the service. For NFS clients, I
> consider it important to be able to do this.
>
> If there is a flaw, it is surely in the thinking of people who
> mistakenly assumed that multi-homed systems would not behave so as to
> allow this.
It is only a flaw when routing is disabled, as we stated.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
ApacheCon 2001! http://ApacheCon.com/
(6179536) ------------------------------------------
Kommentar i text 6180777 av David Litchfield <mnemonix@GLOBALNET.CO.UK>
6180777 2001-03-06 20:18 +0000 /36 rader/ David Litchfield <mnemonix@GLOBALNET.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 23:20 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: mnemonix@GLOBALNET.CO.UK
Mottagare: Bugtraq (import) <15784>
Kommentar till text 6179536 av Ben Laurie <ben@ALGROUP.CO.UK>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: David Litchfield <mnemonix@GLOBALNET.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <000e01c0a67a$af323ce0$839593c3@mnemonix>
> > >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.
> >
This affects Windows NT as well. I spoke of the exact same problem
back in the December of 1998
(http://www.securityfocus.com/vdb/bottom.html?vid=1692 for the BID
and http://oliver.efri.hr/~crv/security/bugs/NT/msproxy3.html for the
details) whereby we could get to the "clean" interface via the
"dirty" interface on MS Proxy II and from there to the rest of the
"protected" network. Mircosoft's response at that time was that this
"feature" was part of the IP routing spec and as such they wouldn't
do anything about it because it would break this spec.
In terms of the threat posed by this "feature" in terms of proxy
servers, like MSP and Squid, this should be control at the
application level. For example, in MSP, you have a Local Address
Table that specifies those IP address that are _allowed_ to use the
proxy services. The dirty interface in not in the LAT so MSP should
dump a request for proxy services if the source IP address is that of
the dirty interface. Why service a request from an IP address if it
is not in the LAT? Unfortunately to my knowledge this is not the way
things are done with MSP or Squid - so perhaps they should.
Cheers,
David Litchfield
Director of Security Architecture
@stake
http://www.atstake.com/
(6180777) --------------------------------(Ombruten)
Kommentar i text 6181226 av Robert Collins <robert.collins@ITDOMAIN.COM.AU>
Kommentar i text 6184710 av Lincoln Yeoh <lyeoh@POP.JARING.MY>
6181226 2001-03-07 09:43 +1100 /68 rader/ Robert Collins <robert.collins@ITDOMAIN.COM.AU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 01:42 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: robert.collins@ITDOMAIN.COM.AU
Mottagare: Bugtraq (import) <15790>
Kommentar till text 6180777 av David Litchfield <mnemonix@GLOBALNET.CO.UK>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Robert Collins <robert.collins@ITDOMAIN.COM.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <021801c0a68e$d75ae8c0$0200a8c0@lifelesswks>
In recent versions (2.3 I believe) Squid has acl types for the
listening port & ip that the request was recieved on, as well as the
source ip of the request. There is no concept of LAT as such, just a
series of acl checks that every request must pass to be serviced.
Thus it is easy for existing users to turn on such a check by editing
their squid.conf.
Rob
----- Original Message -----
From: "David Litchfield" <mnemonix@GLOBALNET.CO.UK>
To: <BUGTRAQ@SECURITYFOCUS.COM>
Sent: Wednesday, March 07, 2001 7:18 AM
Subject: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
> > > >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.
> > >
>
> This affects Windows NT as well. I spoke of the exact same problem
back in
> the December of 1998
(http://www.securityfocus.com/vdb/bottom.html?vid=1692
> for the BID and
http://oliver.efri.hr/~crv/security/bugs/NT/msproxy3.html
> for the details) whereby we could get to the "clean" interface via the
> "dirty" interface on MS Proxy II and from there to the rest of the
> "protected" network. Mircosoft's response at that time was that this
> "feature" was part of the IP routing spec and as such they wouldn't do
> anything about it because it would break this spec.
>
> In terms of the threat posed by this "feature" in terms of proxy
servers,
> like MSP and Squid, this should be control at the application level.
For
> example, in MSP, you have a Local Address Table that specifies those
IP
> address that are _allowed_ to use the proxy services. The dirty
interface in
> not in the LAT so MSP should dump a request for proxy services if the
source
> IP address is that of the dirty interface. Why service a request from
an IP
> address if it is not in the LAT? Unfortunately to my knowledge this is
not
> the way things are done with MSP or Squid - so perhaps they should.
>
> Cheers,
> David Litchfield
> Director of Security Architecture
> @stake
> http://www.atstake.com/
>
(6181226) ------------------------------------------
6184710 2001-03-07 09:47 +0800 /34 rader/ Lincoln Yeoh <lyeoh@POP.JARING.MY>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 17:45 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lyeoh@POP.JARING.MY
Mottagare: Bugtraq (import) <15797>
Kommentar till text 6180777 av David Litchfield <mnemonix@GLOBALNET.CO.UK>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Lincoln Yeoh <lyeoh@POP.JARING.MY>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3.0.5.32.20010307094715.00b8c480@192.228.128.13>
At 08:18 PM 06-03-2001 -0000, David Litchfield wrote:
>
>This affects Windows NT as well. I spoke of the exact same problem back in
>the December of 1998 (http://www.securityfocus.com/vdb/bottom.html?vid=1692
>for the BID and http://oliver.efri.hr/~crv/security/bugs/NT/msproxy3.html
>for the details) whereby we could get to the "clean" interface via the
>"dirty" interface on MS Proxy II and from there to the rest of the
Does it really affect Windows NT?
I find if IP forwarding is on, then yes you can ping its 127.0.0.1
interface (this seems expected to me). But if it's off 127.0.0.1 is
not accessible (just like in Windows 9x).
I tested this sometime last year with Linux 2.0.
Recently I found that Linux 2.2 seems to behave strangely - I couldn't
bring down the lo0 interface and ping a remote 127.0.0.1
Freebsd 4.2 and Linux 2.0 are indeed vulnerable to this multihome
thingy. In fact I did use this feature for a Linux 2.0 firewall - I
used the IPs as DMZ IPs.
However it appears to me that it would be hard to exploit this from a
host more than one network away.
Cheerio,
Link.
(6184710) --------------------------------(Ombruten)
6179960 2001-03-06 17:21 +0000 /18 rader/ David Damerell <djsd100@CAM.AC.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 20:18 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: djsd100@cam.ac.uk
Mottagare: Bugtraq (import) <15769>
Kommentar till text 6179327 av Lothar Beta <lb@ENTERACT.COM>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: David Damerell <djsd100@CAM.AC.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <E14aL9n-00011X-00@libra.cus.cam.ac.uk>
On Mon, 5 Mar 2001, Lothar Beta wrote:
>The default "simple" firewall rules for ipfw in FreeBSD specify that
>packets destined for the 127.0.0.0/8 network not coming from the lo0
>device will be dropped.
Debian GNU/Linux installations nowadays will attempt to set up spoof
protection, with similar effects.
--
David Damerell, Computer Officer, Department of Chemistry, Cambridge
Work: djsd100@cam.ac.uk Personal: damerell@chiark.greenend.org.uk
These are my opinions, not those of the Department as a whole.
(6179960) ------------------------------------------
6180119 2001-03-06 01:09 -0800 /22 rader/ Perry Harrington <pedward@WEBCOM.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 21:01 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15770>
Kommentar till text 6179425 av Ben Laurie <ben@ALGROUP.CO.UK>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
On Tue, Mar 06, 2001 at 09:05:32AM +0000, Ben Laurie wrote:
> when routing is disabled. Further, there's no circumstance I can think
> of where it makes sense to route 127/8 from an external interface! That
It's not 127/8 that we're talking about. You can assign perfectly
valid real world IPs to lo interfaces. The purpose is to get a
machine that listens on an IP but doesn't ARP for it.
> behaviour should not be switchable.
>
> Cheers,
>
> Ben.
>
--Perry
--
Perry Harrington Director of zelur xuniL ()
perry at webcom dot com System Architecture Think Blue. /\
(6180119) --------------------------------(Ombruten)
Bilaga (application/pgp-signature) i text 6180120
Kommentar i text 6180159 av Ben Laurie <ben@ALGROUP.CO.UK>
6180120 2001-03-06 01:09 -0800 /10 rader/ Perry Harrington <pedward@WEBCOM.COM>
Importerad: 2001-03-06 21:01 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: pedward@WEBCOM.COM
Mottagare: Bugtraq (import) <15771>
Bilaga (text/plain) till text 6180119
Ärende: Bilaga till: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (SunOS)
Comment: For info see http://www.gnupg.org
iD8DBQE6pKlVfK7Bvd0wfuURAmP2AKCpzB76DVDsWbwxjVYvdfQSDseWxwCg7MO/
F2BB9pXkAYzIb3WSY44AQPM=
=1sR6
-----END PGP SIGNATURE-----
(6180120) ------------------------------------------
6180159 2001-03-06 10:31 +0000 /30 rader/ Ben Laurie <ben@ALGROUP.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 21:12 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ben@ALGROUP.CO.UK
Mottagare: Bugtraq (import) <15772>
Kommentar till text 6180119 av Perry Harrington <pedward@WEBCOM.COM>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Ben Laurie <ben@ALGROUP.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA4BC8B.A580834F@algroup.co.uk>
Perry Harrington wrote:
>
> On Tue, Mar 06, 2001 at 09:05:32AM +0000, Ben Laurie wrote:
> > when routing is disabled. Further, there's no circumstance I can think
> > of where it makes sense to route 127/8 from an external interface! That
>
> It's not 127/8 that we're talking about. You can assign perfectly valid
> real world IPs to lo interfaces. The purpose is to get a machine that listens
> on an IP but doesn't ARP for it.
You may not be talking about 127/8 but we are (and I freely admit that
may not have been made completely clear).
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
ApacheCon 2001! http://ApacheCon.com/
(6180159) ------------------------------------------
6180167 2001-03-06 11:04 +0100 /12 rader/ J. Bol <j.bol@ITSEC.NL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 21:13 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: j.bol@ITSEC.NL
Mottagare: Bugtraq (import) <15773>
Kommentar till text 6175578 av MaD dUCK <madduck@MADDUCK.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
> 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems
> don't even have a localhost routing entry anymore.
We've been testing with a kernel 2.2.16 victim, which is standard with
RH7.0 and an attacker with kernel 2.0.34. I can see packets comming in
from the attacker, but the kernel does not respond to these.
We also set up an attacker with kernel 2.2.16 and tried the same
attack. No packets arrive on the victim.
jeroen & christian
(6180167) --------------------------------(Ombruten)
Bilaga (application/x-pkcs7-signature) i text 6180168
6180168 2001-03-06 11:04 +0100 /7 rader/ J. Bol <j.bol@ITSEC.NL>
Bilagans filnamn: "smime.p7s"
Importerad: 2001-03-06 21:13 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: j.bol@ITSEC.NL
Mottagare: Bugtraq (import) <15774>
Bilaga (text/plain) till text 6180167
Ärende: Bilaga (smime.p7s) till: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
0j *H÷
[0W1 0 + 0 *H÷
T0P08 0
*H÷
0~1 0 UNL10U
Noord Holland10UHaarlem10U
ITsec Nederland1
0 U EVAS1 0UCertificate Manager0
000823132858Z
010823132858Z01 0 UNL1 0U
ITsec Nederland B.V.1 0U Software engineering10
&ò,djbo10U
Jeroen Bol1 0 *H÷
j.bol@ITsec.nl00
*H÷
0 ÓbÏ_9½ý¤´2´èÕÓ8âF|.³@Ônº3Êðìø âÈb4l+;`íè,Ið´©1BøºüH´ù÷;zY®¦æO]Æä·|BrZ±ö ßÀ`ê.²DUE[¸F^U7Úc0Û",¨ô¸½ £F0D0 `HøB 0U ÿà0 U #0ñI®[¶ÜÕòA@V¡UØb%0
*H÷
îÎk
i
zI8>m»M|m''Ù¯«Fþ)oLcCJÕ¤ÎQ]6£³c
¥ ÿµô{ǧbüâ¶Íóc=6ÀÂįvå¿1Êíùx=ÙFá°ð4ä£^îä=ÝOʯ+udUfHðvwõÚ} *Î¥>¢º;Y -ºwætsúûy 2<ÛèóçSÈÍÃ"Á áYñåc }ìÃÖø£ ®Z+Eè¯ß¼±©¨øH
ø EBôYÒ7i_Sï^#Ö1 7Q¸dÚ®vúÎaÕC%ßt 2xUm1Þ0Ú00~1 0 UNL10U
Noord Holland10UHaarlem10U
ITsec Nederland1
0 U EVAS1 0UCertificate Manager0 + ±0 *H÷
1 *H÷
0 *H÷
1
010306100411Z0# *H÷
1MüìÁuè'ú'Ý)-q^eì0R *H÷
1E0C0
*H÷
0*H÷
0+0
*H÷
@0
*H÷
(0
*H÷
y6AÒÔ»@Ͻ}ºû)?¹áîTR_¢J®1;K ifë &v »-¢
$ÝØWKUÛ, *ª+UüØ0ÌDºãE½ç¢ZÆ;mÐGô¡=^)öx'ô 8·ARØë|éÈÜZ¥T#Ëw}Èf
(6180168) --------------------------------(Ombruten)
6180341 2001-03-06 09:16 +0000 /34 rader/ Ben Laurie <ben@ALGROUP.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 21:56 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ben@ALGROUP.CO.UK
Mottagare: Bugtraq (import) <15775>
Kommentar till text 6175560 av John Cronin <jsc3@HAVOC.GTF.ORG>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Ben Laurie <ben@ALGROUP.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA4AADF.3D027102@algroup.co.uk>
John Cronin wrote:
> > > 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.
A virtual IP bound to the loopback interface is not in 127/8 and so
would not be filtered.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
ApacheCon 2001! http://ApacheCon.com/
(6180341) ------------------------------------------
6180379 2001-03-06 11:26 -0800 /21 rader/ Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 22:02 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: dan-bugtraq@DILVISH.SPEED.NET
Mottagare: Bugtraq (import) <15776>
Kommentar till text 6175624 av Perry Harrington <pedward@WEBCOM.COM>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103061926.LAA24100@dilvish.speed.net>
Perry Harrington <pedward@WEBCOM.COM> writes:
> I don't think the behavior should change because of DSR. DSR is more
> useful than 'rightness' in my opinion. A switch to turn it off if you
> don't want it is something I'd advocate, but the default should be 'on'.
Why? Using direct service return is the unusual case. People who're
doing load-balancing already need to do complex configuration --
what's so big about also having to turn on a flag to use the Weak ES
Model? If you can make the average system more secure by making
Strong ES the default, why not do so?
----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-bugtraq@dilvish.speed.net | do not mention this private email
SpeedGate Communications, Inc. | address in Usenet posts. Thank you.
(6180379) --------------------------------(Ombruten)
6180408 2001-03-06 11:48 +0000 /44 rader/ Lars Mathiesen <syl@ECMWF.INT>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 22:08 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: syl@ECMWF.INT
Mottagare: Bugtraq (import) <15777>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Lars Mathiesen <syl@ECMWF.INT>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <1010306114838.ZM6221@fafnir>
On Mar 5, 20:07, Neil W Rickert wrote:
> I am surprised to see this described as a flaw. It is behavior I
> have been relying on for some time. Specifically, on my client
> machines, I add a route to the alternate interface of my servers via
> the direct interface of the same server. This allows direct
> connection to the server without relying on a router, regardless of
> which IP address is used for the service. For NFS clients, I
> consider it important to be able to do this.
We use a similar trick to provide failover between internal LANs for
our servers: Every functioning interface announces the 'well-known'
server address via a routing protocol, and the clients either run
gated or rely on a router to pick the best route that they see an
announcement for.
> If there is a flaw, it is surely in the thinking of people who
> mistakenly assumed that multi-homed systems would not behave so as to
> allow this.
I concur totally. Back when I designed security solutions (admittedly
high end) for a living, best practice was that any system with a
reason to distinguish its interfaces must have the less secure one on
a dedicated LAN segment to a real router with antispoofing filters in
place. And that includes commercial firewalls.
(Of course a firewall should by default discard packets arriving at
the wrong interface, but better safe than sorry).
The farm of misconfigured NT web servers should be on a different LAN
interface on the router, so rooting one won't enable an attacker to
install password sniffers or send malformed or misrouted packets to
the firewall/ mail gateway/ whatever.
--
Lars.Mathiesen@ecmwf.int
ECMWF, Shinfield Park,
Reading, Berks.
RG2 9AX England
(6180408) --------------------------------(Ombruten)
6180460 2001-03-06 08:58 -0500 /46 rader/ Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 22:17 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ksparger@DIALTONEINTERNET.NET
Mottagare: Bugtraq (import) <15778>
Kommentar till text 6175578 av MaD dUCK <madduck@MADDUCK.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Kyle Sparger <ksparger@DIALTONEINTERNET.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <Pine.LNX.4.10.10103060832550.27400-100000@kyle>
Mad Duck wrote:
> 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems
> don't even have a localhost routing entry anymore.
Actually I can confirm that Linux 2.4 does suffer from it, at least
in the hardwired MAC address case I mentioned. Just took the time to
test it.
Andrew Bartlett wrote:
> I'm trying to assess how this affects me. Is Linux 2.2 vulnerable when
> rp_filter is enbled (sys.net.ipv4.all.rp_filter)? If so then the above
> statement is correct, as rp_filter is enabled by default on RedHat
> installs.
I'm reading the documentation on rp_filter
(Documentation/Configure.help).
In sum, it appears to implement the command 'ip verify unicast
reverse-path' that you would find on Cisco routers :) Or am I
misunderstanding?
Assuming I'm reading it correctly, then this will not protect you.
The feature only matches against the source, which is not the issue
here.
RoMaN SoFt / LLFB !! wrote:
> I've not tested it but perhaps this is a valid workaround for Linux.
I don't think so. Just follow the maintainer's advice, and filter
your interfaces:
# ifconfig eth0 10.0.5.10
# ipchains -A input -i eth0 -d 10.0.5.10 -j ACCEPT
# ipchains -A input -i eth0 -j DENY
Or something like that, anyway. Easy enough, right? :)
Thanks,
Kyle Sparger - Senior System Administrator
ksparger@dialtoneinternet.net - http://www.dialtoneinternet.net
Voice - (954) 581-0097 x 122
"Forget college, I'm going pro."
(6180460) --------------------------------(Ombruten)
6180532 2001-03-06 13:34 +0300 /47 rader/ 3APA3A <3APA3A@SECURITY.NNOV.RU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 22:35 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: 3APA3A@SECURITY.NNOV.RU
Mottagare: Bugtraq (import) <15782>
Kommentar till text 6174585 av Woody <woody@THEBUNKER.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: 3APA3A <3APA3A@SECURITY.NNOV.RU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <173678817147.20010306133418@SECURITY.NNOV.RU>
Hello Woody,
Monday, March 05, 2001, 10:44:43 PM, you wrote:
W> There is a flaw in the TCP/IP stack, such that packets intended for
W> loopback and/or local network interfaces, routed via any other
W> interface, will be delivered EVEN IF THE MACHINE IS CONFIGURED NOT
W> TO BE A GATEWAY (note that in the case of packets destined for the
W> loopback interface, we consider this to be a fault no matter how
W> the host is configured - see RFC 1122 comments below). This means
W> that connections can be made to services that were intended to be
W> invisible by virtue of the fact that they were only listening on
W> the "inside" of a system. This may lead to further compromise of
W> the host and/or connected networks, either via (e.g.) buffer
W> overflows or enhanced privileges via access to SOCKS or other
W> internal proxies.
Windows NT behaves same way - it will accept connection to internal
address through external interface even if routing is not enabled (I'm
not sure about loopback). Then configuring Cisco routers it's quite
common practice to give real address to loopback interface and link
this address to few external interfaces.
This behavior doesn't violate RFC 1122. And I believe this behavior is
correct (imagine host with e.g. few PPTP and L2TP interfaces, some of
them may be dynamically addressed. To make access to this host from
outside you may want some static internal address, may be linked to
loopback, rather then virtual interface or any physical interface, but
enabling routing in this case isn't good idea).
I believe solution for this problem may be something like
ipfw add allow all via lo*
ipfw add deny all to 127.0.0.0/8
if you want this behavior to be changed.
--
~/3APA3A
Åñëè äàæå âû ïîëó÷èòå êàêîå-íèáóäü ïèñüìî, âû âñå ðàâíî íå ñóìååòå åãî ïðî÷èòàòü. (Òâåí)
(6180532) ------------------------------------------
Kommentar i text 6181208 av bert hubert <ahu@DS9A.NL>
Kommentar i text 6181225 av Martin Macok <martin.macok@UNDERGROUND.CZ>
6181208 2001-03-06 23:01 +0100 /31 rader/ bert hubert <ahu@DS9A.NL>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 01:18 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ahu@DS9A.NL
Mottagare: Bugtraq (import) <15786>
Kommentar till text 6180532 av 3APA3A <3APA3A@SECURITY.NNOV.RU>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: bert hubert <ahu@DS9A.NL>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010306230140.A15450@home.ds9a.nl>
On Tue, Mar 06, 2001 at 01:34:18PM +0300, 3APA3A wrote:
> Windows NT behaves same way - it will accept connection to internal
> address through external interface even if routing is not enabled (I'm
> not sure about loopback). Then configuring Cisco routers it's quite
One thing that hasn't been clearly stated, although it's obvious to
experts: this vulnerability is only available for people who are
already on your subnet.
So it IS a 'remote vulnerability' but only for people who are on your
subnet. So if you have a DMZ with no untrusted computers on the
subnet, this will not harm you.
I still feel that this is a pretty stupid oversight - if routing is
switched off as it SHOULD or even MUST be on a host, this is not
supposed to happen.
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Services
Trilab The Technology People
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
(6181208) --------------------------------(Ombruten)
Kommentar i text 6181305 av Crist Clark <crist.clark@GLOBALSTAR.COM>
6181305 2001-03-06 16:28 -0800 /23 rader/ Crist Clark <crist.clark@GLOBALSTAR.COM>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 03:52 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: crist.clark@GLOBALSTAR.COM
Mottagare: Bugtraq (import) <15792>
Kommentar till text 6181208 av bert hubert <ahu@DS9A.NL>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Crist Clark <crist.clark@GLOBALSTAR.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA580A5.D78FF744@globalstar.com>
bert hubert wrote:
[snip]
> I still feel that this is a pretty stupid oversight - if routing is switched
> off as it SHOULD or even MUST be on a host, this is not supposed to happen.
People keep saying this and I don't think they mean it. "ROUTING" is
never turned off on host doing IP (at least I can't think of a
counter- example). Your average host probably has a default route, it
has a loopback route, lots of hosts have a m-cast route,
etc. Multihomed hosts are always going to have even more complicated
routing tables.
I think you mean, "if FORWARDING is switched off..."
--
Crist J. Clark Network Security Engineer
crist.clark@globalstar.com Globalstar, L.P.
(6181305) --------------------------------(Ombruten)
6181225 2001-03-06 23:05 +0100 /44 rader/ Martin Macok <martin.macok@UNDERGROUND.CZ>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 01:41 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: martin.macok@UNDERGROUND.CZ
Mottagare: Bugtraq (import) <15789>
Kommentar till text 6180532 av 3APA3A <3APA3A@SECURITY.NNOV.RU>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Martin Macok <martin.macok@UNDERGROUND.CZ>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010306230517.H910@sarah.kolej.mff.cuni.cz>
On Tue, Mar 06, 2001 at 01:34:18PM +0300, 3APA3A wrote:
> I believe solution for this problem may be something like
>
> ipfw add allow all via lo*
> ipfw add deny all to 127.0.0.0/8
>
> if you want this behavior to be changed.
(In case Linux 2.4 ''suffer'' ...
I had no time to test it but others (Kyle Sparger) claimed that)
In netfilter/iptables (linux 2.4) language:
### ALLOW EVERTHING FROM lo AND DISABLE EVERYTHING ELSE TO 127.0.0.*
iptables -A INPUT -i lo -j ACCEPT
# if you want some logging, uncomment next line:
# iptables -A INPUT -d 127.0.0.0/8 -m limit --limit 5/minute -j LOG
iptables -A INPUT -d 127.0.0.0/8 -j DROP
OR similar strategy:
### DISABLE EVERYTHING TO 127.0.0.* NOT COMING FROM lo
# if you want some logging, uncomment next line:
# iptables -A INPUT -d 127.0.0.0/8 -i ! lo -m limit --limit 5/minute -j LOG
iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j DROP
I vote for 'Strong ES Model' by default (especially for linux as it
becomes often installed by clueless beginners) and there is no
argument for making 'Weak ES Model' default. Including the fact that
almost no current Security-HOWTO's/Firewall-HOWTO's/Networking-HOWTO's
don't discuss that topic ...
Have a nice day
--
Martin Maèok
underground.cz
openbsd.cz
(6181225) ------------------------------------------
Kommentar i text 6185149 av 3APA3A <3APA3A@SECURITY.NNOV.RU>
6185149 2001-03-07 15:12 +0300 /51 rader/ 3APA3A <3APA3A@SECURITY.NNOV.RU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 19:23 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: 3APA3A@SECURITY.NNOV.RU
Mottagare: Bugtraq (import) <15801>
Kommentar till text 6181225 av Martin Macok <martin.macok@UNDERGROUND.CZ>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: 3APA3A <3APA3A@SECURITY.NNOV.RU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <1318151040.20010307151224@SECURITY.NNOV.RU>
Hello Martin,
Wednesday, March 07, 2001, 1:05:17 AM, you wrote:
MM> there is no argument for making 'Weak ES Model' default. Including
Catch one: changing security model will give additional undesired work
for administrators. Situation where multihomed host has services
binded to all interfaces is more common then situation where
multihomed host has a services binded to single interface. I do not
feel myself guru in this question. But I see no enough security risk
in this problem to change default behavior, essentially for multihomed
hosts. Nevertheless it could be nice to have configuration option,
something like "disable internal routing".
MM> the fact that almost no current
MM> Security-HOWTO's/Firewall-HOWTO's/Networking-HOWTO's don't discuss
MM> that topic ...
It's a good point to update HOWTO's. They MUST discuss this topic
regardless of results of this flame. Linux HOWTO's must be updated
long time ago, because they are incomplete and miss a lot of key
moments. Example:
Firewall-HOWTO from www.linux.org Updated: February 2000. IP
filtering setup (IPFWADM and IPCHAINS) section. Demo rules make false
sense of security, because external hacker can access whole network
by UDP using source port 53 (destination port never checked) and all
unprivileged TCP ports using source port 80 (connection doesn't
checked to be established). Nearly same problem in Linux
IPCHAINS-HOWTO.
Sorry, if I chose wrong source for getting HOWTO's - I'm not from
Linux world.
MM> Have a nice day
--
~/3APA3A
Íåïðèÿòíîñòè íà÷íóòñÿ â âîñåìü. (Òâåí)
(6185149) ------------------------------------------
6180672 2001-03-05 22:22 -0700 /39 rader/ Kurt Seifried <bugtraq@SEIFRIED.ORG>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-06 23:02 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: bugtraq@SEIFRIED.ORG
Mottagare: Bugtraq (import) <15783>
Kommentar till text 6175578 av MaD dUCK <madduck@MADDUCK.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Kurt Seifried <bugtraq@SEIFRIED.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <006c01c0a5fd$6caf2360$3200030a@seifried.org>
Kurt Seifried, seifried@securityportal.com
Securityportal - your focal point for security on the 'net
> 2.2 is vulnerable, but 2.4 is not. as far as i can tell, 2.4 systems
> don't even have a localhost routing entry anymore.
>
> martin
Huh?
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16128 Metric:1
RX packets:46 errors:0 dropped:0 overruns:0 frame:0
TX packets:46 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
[root@stench /root]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.3.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.3.0.1 0.0.0.0 UG 0 0 0 eth0
[root@stench /root]# uname -a
Linux stench.seifried.org 2.4.0-0.26 #1 Fri Aug 25 08:31:55 EDT 2000 i686
unknown
It does in older 2.4.0's, haven't tried 2.4.1/2.4.2 however.
Kurt Seifried, seifried@securityportal.com
Securityportal - your focal point for security on the 'net
(6180672) ------------------------------------------
6181197 2001-03-06 22:30 +0000 /51 rader/ Ben Laurie <ben@ALGROUP.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 01:09 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: ben@ALGROUP.CO.UK
Mottagare: Bugtraq (import) <15785>
Ärende: Re: [Fwd: Re: Loopback and multi-homed routing flaw in TCP/IP
------------------------------------------------------------
stack.]
From: Ben Laurie <ben@ALGROUP.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA564FF.456C379@algroup.co.uk>
Aleph1 wrote:
> A flaw in the standard not on the stack. RFC 1122 "Requirements for
> Internet
> Hosts -- Communication Layers" covers this issue although without
> pointing
> out its security consequences.
In the case that a host is not routing, it is abundantly clear that
the strong model is the only correct one. Similarly, I would argue
that in the case that a host is routing, the weak model is clearly
correct. In more complex cases, one should use packet filtering to
enforce requirements. You'll note that RFC 1122 is completely silent
on the difference between routing and non-routing hosts, which makes
it so broken it seems almost irrelevant on this issue.
But the really important point in our advisory which is independent
of these considerations is that packets can be delivered to
localhost, err, remotely.
RFC 1122 is actually somewhat flawed in this respect, too, in that it
makes it a requirement that 127/8 packets should not appear on the
network, without specifying the behaviour of hosts upon receipt of
such an illegal packet (which by the default "be liberal in what you
receive" rule should handle them gracefully, rather than sensibly
discarding them).
But the bottom line is this: regardless of RFCs, it is clear how the
systems should be expected to behave, and if they don't behave that
way, they are broken. If the RFCs also make it "legal" for them to be
broken, then they, in turn, are also broken. So, yes, RFC 1122
"covers" this issue, but so hopelessly it is hardly worth
considering. I have to wonder what the authors were thinking of!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
ApacheCon 2001! http://ApacheCon.com/
(6181197) --------------------------------(Ombruten)
Kommentar i text 6185296 av Darren Reed <avalon@COOMBS.ANU.EDU.AU>
6185296 2001-03-07 19:03 +1100 /45 rader/ Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 19:58 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: avalon@COOMBS.ANU.EDU.AU
Mottagare: Bugtraq (import) <15803>
Kommentar till text 6181197 av Ben Laurie <ben@ALGROUP.CO.UK>
Ärende: Re: [Fwd: Re: Loopback and multi-homed routing flaw in TCP/IP
------------------------------------------------------------
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103070803.TAA13933@cairo.anu.edu.au>
In some mail from Ben Laurie, sie said:
>
> Aleph1 wrote:
> > A flaw in the standard not on the stack. RFC 1122 "Requirements for
> > Internet
> > Hosts -- Communication Layers" covers this issue although without
> > pointing
> > out its security consequences.
>
> In the case that a host is not routing, it is abundantly clear that the
> strong model is the only correct one. Similarly, I would argue that in
> the case that a host is routing, the weak model is clearly correct. In
> more complex cases, one should use packet filtering to enforce
> requirements. You'll note that RFC 1122 is completely silent on the
> difference between routing and non-routing hosts, which makes it so
> broken it seems almost irrelevant on this issue.
Let me give you a 'counter example'. Multi-homed server of some
kind, and a client goes to access it. DNS server gives a reply with
all of the addresses included. Which one does the client choose ?
Should it have to check them all for the "best match" ? What if it
can't work out what is the "best match" ? The client should be able
to pick "any address" and connect, no ? Afterall, the intention is
to provide a service to clients. Whether the server listens on one
address (as it might) or all interface addreses or just "ANY" (all
are quite valid scenarios), if it is a general service then I
generally want everyone to access it and what it's bound to should be
neither here nor there. It should "just work".
I don't mention if it is a routing or non-routing server because it
makes no difference to me, as a client - or shouldn't at any rate.
I've seen a lot of people say "Strong ES model" should be the default,
but that is only a requirement for particular applications where you
want that behaviour.
To answer your question about what the RFC authors meant, maybe they
were thinking of actually just "using" multi-homed servers rather
than trying to impose security restrictions.
(6185296) --------------------------------(Ombruten)
6181219 2001-03-07 09:58 +1100 /48 rader/ Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 01:28 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: avalon@COOMBS.ANU.EDU.AU
Mottagare: Bugtraq (import) <15787>
Kommentar till text 6174585 av Woody <woody@THEBUNKER.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <200103062258.JAA07191@cairo.anu.edu.au>
In some mail from Woody, sie said:
>
> 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.
No, I think you should have listened to people before you posted
this. You clearly didn't, on a number of different fronts, including
that for Solaris. Really, if you're going to post a security
advisory and want to comment about Solaris you should at least go to
the trouble of getting the Solaris8 source code, for a recent
reference.
The localhost issue where remote hosts can connect to localhost
addresses on other boxes is an issue, yes, but the other...no.
Much has been said about the strong vs weak ES model here so I'll not
debate that any further. Suffice to say that it wasn't as unknown as
you wanted to claim and people were happy with it. As you've been
made aware, it's been known as a bug in NetBSD since 1995.
The other part of your advisory is the argument that IP addresses on
an interface should not be reachable, by default, through others
because people bind things to particular interfaces for security
reasons and that people would be surprised to find out it's not like
that. Well, any admin who's setup something like that and gone on to
not test his configuration is being careless. The expectation of
implied filtering of packets is an illusion created by that person
for themselves. I've not read anywhere that the behaviour is
documented to be such. Your claim that this is wrong is just your
opinion and typically security advisories are based on factual
security flaws, not opinions. The security problem here is in people
not testing "security" they think they have put in place.
(6181219) --------------------------------(Ombruten)
Kommentar i text 6181320 av Woody <woody@THEBUNKER.NET>
6181320 2001-03-07 00:45 +0000 /49 rader/ Woody <woody@THEBUNKER.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 04:20 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: woody@THEBUNKER.NET
Mottagare: Bugtraq (import) <15793>
Kommentar till text 6181219 av Darren Reed <avalon@COOMBS.ANU.EDU.AU>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Woody <woody@THEBUNKER.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA584A2.F8D3E37D@thebunker.net>
Darren Reed wrote:
>
> In some mail from Woody, sie said:
> >
> > 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.
>
[snip]
> The other part of your advisory is the argument that IP addresses on
> an interface should not be reachable, by default, through others because
> people bind things to particular interfaces for security reasons and
> that people would be surprised to find out it's not like that. Well,
> any admin who's setup something like that and gone on to not test his
> configuration is being careless. The expectation of implied filtering
> of packets is an illusion created by that person for themselves. I've
> not read anywhere that the behaviour is documented to be such. Your
> claim that this is wrong is just your opinion and typically security
> advisories are based on factual security flaws, not opinions. The
> security problem here is in people not testing "security" they think
> they have put in place.
Yes, `people not testing "security" they think they have put in
place' is a valid point, to an extent. However, when people test
their systems, they test the things that they deem to be within the
realms of possibility. A machine which has routing turned off, is
not _expected_ to route, so it is not tested for. This is the point
of this advisory, which is commonly missed.
Woody
(6181320) --------------------------------(Ombruten)
Kommentar i text 6184940 av Lupe Christoph <lupe@LUPE-CHRISTOPH.DE>
6184940 2001-03-07 08:59 +0100 /47 rader/ Lupe Christoph <lupe@LUPE-CHRISTOPH.DE>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 18:29 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: lupe@LUPE-CHRISTOPH.DE
Mottagare: Bugtraq (import) <15799>
Kommentar till text 6181320 av Woody <woody@THEBUNKER.NET>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Lupe Christoph <lupe@LUPE-CHRISTOPH.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010307085909.G1243@alanya.lupe-christoph.de>
On Wednesday, 2001-03-07 at 00:45:22 +0000, Woody wrote:
> A machine which has routing turned off, is not _expected_ to route, so
> it
> is not tested for.
> This is the point of this advisory, which is commonly
> missed.
You mean forwarding, not routing, I suppose?
Forwarding means that a router sends packets received on one interface
out to another interface, hence the term.
It does not mean the reachability of one interface of the router
by packets received on another. That's multi-homing.
As has been repeatedly pointed out to you, allowing this is
desirable in many situations (I'm not talking about 127/8 here,
this interface should not be reachable from the outside).
I have a lot of clients relying on this. They would be thoroughly
confused if their multihomed hosts would use strict multihoming.
As for machines multihomed to different security zones - they
are relatively rare. Requiring *all* hosts to use strict multihoming
just because a few people could overlook a behaviour that could
compromise security in very few situations is overreacting.
I propose you retract your advisory because (as has been pointed out)
it isn't one. Instead, try to get vendors to implement *optional*
strict multihoming if they haven't already.
It saves on rulesets in IP Chains, Tables, Filter, etc. If you really
need it, that is.
Lupe Christoph
--
| lupe@lupe-christoph.de | http://free.prohosting.com/~lupe |
| I have challenged the entire ISO-9000 quality assurance team to a |
| Bat-Leth contest on the holodeck. They will not concern us again. |
| http://public.logica.com/~stepneys/joke/klingon.htm |
(6184940) ------------------------------------------
6185284 2001-03-07 16:26 +0100 /35 rader/ Kenny Jansson <kenson@SENTOR.SE>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-07 19:56 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: kenson@SENTOR.SE
Mottagare: Bugtraq (import) <15802>
Ärende: Broadcast and multi-homed routing condition in TCP/IP stack.
------------------------------------------------------------
From: Kenny Jansson <kenson@SENTOR.SE>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010307162641.D27909@sentor.se>
In light of the current discussion about the "Loopback and
multi-homed routing flaw in TCP/IP stack." it's worth mentioning
another "condition" that exists in some TCP/IP stacks.
Some stacks will allow TCP connection to be established to the
broadcast address configured on any given interface.
FreeBSD has had this behaviour for some time 4.x
up until 2001/03/03 17:39:20 PST when a fix was comitted to RELENG_4
OpenBSD also exhibits this behaviour. (Tested on 2.7)
Linux and Solaris don't.
The reason this condition is worth mention is for the cases when
you expect a number of external addresses to be exposed and you apply
excplicit filtering on those addresses, and wrongly assume that no
other endpoints exists to establish connections to.
Obvious fix of course if running FreeBSD is to update your kernel to
incorporate the commited fix. Obvious workaround is to always
practice safe networking, deny everything, then explicitly allow what
should be allowed.
/Kenny
--
Kenny Jansson kenson@sentor.se
Sentor AB, Västra Strandg. 7B, 753 11 Uppsala, Sweden
phn: +46 (0) 18 65 30 00 | gsm: +46 (0) 70 757 30 01
(6185284) --------------------------------(Ombruten)
Kommentar i text 6186835 av Charles M. Hannum <root@IHACK.NET>
6186835 2001-03-07 10:55 -0800 /30 rader/ Charles M. Hannum <root@IHACK.NET>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-08 08:06 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: root@IHACK.NET
Mottagare: Bugtraq (import) <15816>
Kommentar till text 6185284 av Kenny Jansson <kenson@SENTOR.SE>
Ärende: Re: Broadcast and multi-homed routing condition in TCP/IP stack.
------------------------------------------------------------
From: "Charles M. Hannum" <root@IHACK.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20010307105515.A29517@mail.netbsd.org>
On Wed, Mar 07, 2001 at 04:26:41PM +0100, Kenny Jansson wrote:
>
> Some stacks will allow TCP connection to be established to the broadcast
> address configured on any given interface.
>
> FreeBSD has had this behaviour for some time 4.x
> up until 2001/03/03 17:39:20 PST when a fix was comitted to RELENG_4
>
> OpenBSD also exhibits this behaviour. (Tested on 2.7)
A few notes. Net/2 and 4.4BSD had explicit code of the form:
case TCPS_LISTEN: {
...
if (m->m_flags & M_BCAST)
goto drop;
...
This code lives on in a slightly different form in all of the systems
today.
It's true that this doesn't catch packets that are sent by Ethernet
unicast to the IP broadcast address. I'm not sure what the prevailing
opinion on this is, but we should probably filter such packets.
(6186835) ------------------------------------------
6187093 2001-03-07 18:14 +0000 /82 rader/ Adam Laurie <adam@ALGROUP.CO.UK>
Sänt av: joel@lysator.liu.se
Importerad: 2001-03-08 09:17 av Brevbäraren (som är implementerad i) Python
Extern mottagare: BUGTRAQ@SECURITYFOCUS.COM
Externa svar till: adam@ALGROUP.CO.UK
Mottagare: Bugtraq (import) <15817>
Ärende: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
------------------------------------------------------------
From: Adam Laurie <adam@ALGROUP.CO.UK>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <3AA67A6B.1FE77230@algroup.co.uk>
> In some mail from Woody, sie said:
> >
> > 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.
>
> No, I think you should have listened to people before you posted this.
> You clearly didn't, on a number of different fronts, including that for
> Solaris. Really, if you're going to post a security advisory and want
> to comment about Solaris you should at least go to the trouble of getting
> the Solaris8 source code, for a recent reference.
We have no interest in reviewing commercial operating
systems. Specific solaris versions were tested in a very basic
fashion to see if they were vulnerable out of box, as a
checkpoint. The advisory specifically stated that further
investigation was advised. If you or anyone else wish to do that
investigation, or have already done so, and report your findings,
that can only be of benefit of the community.
>
> The localhost issue where remote hosts can connect to localhost addresses
> on other boxes is an issue, yes, but the other...no.
>
> Much has been said about the strong vs weak ES model here so I'll not
> debate that any further. Suffice to say that it wasn't as unknown as
> you wanted to claim and people were happy with it. As you've been made
> aware, it's been known as a bug in NetBSD since 1995.
We already knew it was known - that's why the opening paragraph says
so. However, things have moved on considerably since 1995 and there
are now thousands of new players in the unix hosting game, not all of
whom have the expert knowledge you have. Issues like this need to be
revisited from time to time, and prioritised in the light of the
prevailing levels of competence. We all know that experts can secure
their systems in all kinds of elegant and interesting ways, but the
average unix administator is now far from expert, and getting less so
every day. We can either leave them to the sharks/kiddies, or try and
help them. We happen to want to try and help them.
>
> The other part of your advisory is the argument that IP addresses on
> an interface should not be reachable, by default, through others because
> people bind things to particular interfaces for security reasons and
> that people would be surprised to find out it's not like that. Well,
> any admin who's setup something like that and gone on to not test his
> configuration is being careless. The expectation of implied filtering
> of packets is an illusion created by that person for themselves. I've
> not read anywhere that the behaviour is documented to be such. Your
> claim that this is wrong is just your opinion and typically security
> advisories are based on factual security flaws, not opinions. The
> security problem here is in people not testing "security" they think
> they have put in place.
Actually it appears to be the opinion of the majority of the security
conscious community, which is why the problem is being addressed, and
since that's what matters I'm happy to let it rest here.
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:adam@algroup.co.uk
UNITED KINGDOM PGP key on keyservers
(6187093) --------------------------------(Ombruten)