netdev - Re: loopback IP alias breaks tftp?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAA6X_dP_LDO0hQYpixi-DtsKVJZQEgAY5wa4y_wYpEqXVyn7TQ@mail.gmail.com>
Date:	Fri, 7 Oct 2011 18:02:57 +1100
From:	Joel Sing <jsing@...gle.com>
To:	Josh Boyer <jwboyer@...hat.com>
Cc:	Julian Anastasov <ja@....bg>, netdev@...r.kernel.org
Subject: Re: loopback IP alias breaks tftp?

On 7 October 2011 00:23, Josh Boyer <jwboyer@...hat.com> wrote:
>
> On Thu, Oct 06, 2011 at 12:18:44AM +0300, Julian Anastasov wrote:
> >
> >       Hello,
> >
> > On Wed, 5 Oct 2011, Josh Boyer wrote:
> >
> > > Hi All,
> > >
> > > We've had a report [1] of a change in behavior when trying to use an IP
> > > alias to tftp from a loopback device.  Apparently the steps outlined in
> > > the bug worked in 2.6.35, and broke somewhere before 2.6.38.6.
> > >
> > > I can confirm the steps fail on a 3.0 based kernel and I'm trying to do
> > > a git bisect to find the commit involved, but I thought I would send
> > > this along to see if anyone might have an idea.  (Also, I'm not really
> > > sure how valid of a usecase this was to begin with.)
> >
> >       What about commit 9fc3bbb4a752f108cf096d96640f3b548bbbce6c ?
> >
> > ipv4/route.c: respect prefsrc for local routes
> >
> > http://marc.info/?t=129412232500001&r=1&w=2
> >
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=739534
>
> Yep.  That is exactly what my git bisect said too.
>
> So now we have a change in behavior since that commit for the usecase
> described in the bug above, but I'm unsure if that usecase was ever
> really valid or if the commit had unintentional side effects.
>
> Joel (or anyone else) can you take a look and comment?

Prior to this commit the src address in the local routing table was
completely ignored, so connecting to a local address always used the
same source and destination addresses. However, this is not what was
configured in the local routing table:

  $ ifconfig lo:0 127.0.0.2
  $ ip route show table local | grep 127.0.0.2
  local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.1

When an interface has an alias configured, the source address
installed in the local routing table is always the primary address for
the interface. The tftp use case you've described now breaks due to
the way that in.tftpd is determining the reply address (as documented
in the in.tftpd manual page). This means that it is now responding
from 127.0.0.1 even though the client connected to 127.0.0.2. Binding
inetd to a specific address will avoid this issue.

I have not yet looked to see if there is a specific reason for the
source address selection, however one way of restoring the previous
behaviour (whilst still respecting the configured source address)
would be to use a default source address which matches the configured
address (as is done for primary addresses). I cannot immediately think
of a reason not to do this, but I've not gone looking at the code.

Worst case scenario if you specifically need the original behaviour
then the source address can be changed in the local routing table:

  $ ip route change table local local 127.0.0.2 dev lo:0 proto kernel
scope host src 127.0.0.2
  $ ip route show table local | grep 127.0.0.2
  local 127.0.0.2 dev lo  proto kernel  scope host  src 127.0.0.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html