Bugtraq mailing list archives
Re: Loopback and multi-homed routing flaw in TCP/IP stack.
From: Robert Collins <robert.collins () ITDOMAIN COM AU>
Date: Wed, 7 Mar 2001 09:43:17 +1100
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/
Current thread:
- Re: Loopback and multi-homed routing flaw in TCP/IP stack., (continued)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Ben Laurie (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Dan Harkless (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Kyle Sparger (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. MaD dUCK (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. J. Bol (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Kyle Sparger (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Kurt Seifried (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. MaD dUCK (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Neil W Rickert (Mar 05)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Ben Laurie (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. David Litchfield (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Robert Collins (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Lincoln Yeoh (Mar 07)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Ben Laurie (Mar 06)
- Message not available
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Lars Mathiesen (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. David Damerell (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Martin Macok (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. 3APA3A (Mar 07)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. bert hubert (Mar 06)
- Re: Loopback and multi-homed routing flaw in TCP/IP stack. Crist Clark (Mar 06)