At 08:18 PM 06-03-2001 -, 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)
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
On Wednesday, 2001-03-07 at 00:45:22 +, 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
In some mail from Woody, sie said:
Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
Author: Woody [EMAIL PROTECTED]
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
Perry Harrington wrote:
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'.
The FreeBSD guys are making the behaviour switchable
Greetinks,
On Mon, Mar 05, 2001 at 07:44:43PM +, Woody wrote:
Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
Author: Woody [EMAIL PROTECTED]
[snip]
must be configured, using a firewall, to drop IP packets arriving from
the wrong network in order to be secure
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
On Tue, Mar 06, 2001 at 09:05:32AM +, 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
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
Perry Harrington wrote:
On Tue, Mar 06, 2001 at 09:05:32AM +, 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
Perry Harrington [EMAIL PROTECTED] 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
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
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
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
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
Kurt Seifried, [EMAIL PROTECTED]
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?
loLink encap:Local Loopback
inet
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,
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
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
In some mail from Woody, sie said:
Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
Author: Woody [EMAIL PROTECTED]
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
technic
users to turn on such a check by editing
their squid.conf.
Rob
- Original Message -
From: "David Litchfield" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 07, 2001 7:18 AM
Subject: Re: Loopback and multi-homed routing flaw in TCP/IP stack.
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
Darren Reed wrote:
In some mail from Woody, sie said:
Subject: Loopback and multi-homed routing flaw in TCP/IP stack.
Author: Woody [EMAIL PROTECTED]
We believe there to be a serious security flaw in the TCP/IP stack of
several Unix-like operating systems. Whilst being "
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.
From section 3.3.4.2 Multihoming Requirements:
There are two key requirement issues related to multihoming:
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
: Loopback and multi-homed routing flaw in TCP/IP stack.
Author: Woody [EMAIL PROTECTED]
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
calling for people to change this functionality is
unwarranted when machines can be firewalled.
Or there's an option to turn it off, e.g. Solaris -
/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1
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
Woody [EMAIL PROTECTED] 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
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
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
and multi-homed routing flaw in TCP/IP stack.
Author: Woody [EMAIL PROTECTED]
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
32 matches
Mail list logo
