[My apologies for getting into this thread rather late, but I just
came across this on a network I'm working with which is all on the
same switch/VLAN... I had 2 network cards per machine and was
puzzled why traffic destined for one interface went to the other]
Julian Anastasov <ja@ssi.bg> wrote:
> Szekeres Bela wrote:
>
> > I've seen a similar bug in 2.2.19 (and a lot of 2.2-s, I've not checked it in
> > the 2.4 series).
>
> In your case
>
> > --------------------------- 10.1.0.0 (tr)
> > |.1 |.2
> > BOX1 BOX2 BOX3
> > |.1 |.2 |.3
> > --------------------------- 10.2.0.0 (eth)
>
> it is a feature, may be not fully utilized without using
> alternative link routes. At least, I don't know for any standard
> that is not followed from this feature. IMO, the following fix
> is more correct:
>
> 01_arp_prefsrc-2.2.19-4.diff
> or
> 01_arp_prefsrc-2.4.12-5.diff
> from
> http://www.linuxvirtualserver.org/~julian/#routes
>
> its main usage is for devices attached to same medium but should
> work for your case too. It always uses the preferred source IP
> to the target because any local IP addresses announced in our probes
> are updated in the remote ARP caches and in some cases it is not
> the desired behavior. Even the Linux's rp_filter protection can't
> avoid the ARP cache entry update. It could be a "problem" when BOX2 uses
> devices attached to same medium. Other users are happy with such
> feature because if eth0 fails may be eth1 still have link to the
> same hub, for example.
This is *not* a feature, it is a major security hole.
Let's say you have a firewall running Linux. Oops, I can spoof the
external interface to accept traffic as if it's the internal one.
I may have screwed up my test, but it looks like it just worked on
my RedHat 7.2 based most recent 2.4.9-21 kernel on my firewall!!
This is Not Good.
You can imagine, I just added the proc command to shut it off to
my setup.
I'm not sure (haven't checked it yet), but I would guess that
there still may be a hole here (and in my config) where a machine
on the same network could craft packets that will get accepted
by my machine even though it doesn't respond to arps on that
interface any more.
I.e. the machine still may be accepting traffic destined for one
interface on another, even though it won't *advertise* that fact
any more.
If so, this is yet another bug which is dangerous in configs
like firewalls.
The fact that you have to manually turn this off is insane. I must
admit to being kind of angry that it was considered a "feature"
when discovered, and left in.
Am I the only one that saw this kind of scary hole?
These kind of "features" that cause weird behavior should always
be turned off by default, else corner cases like this sometimes
pop up.
Sorry about the mild flameage here, but this does make me wonder what
other "features" there are that might be exploitable.
--
Erich Stefan Boleyn <erich@uruk.org> http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:24 EST