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

[Darren Reed <avalon () COOMBS 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.