Message ID | 20110928171952.0c0d2d05@asterix.rh |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
From: Flavio Leitner <fbl@redhat.com> Date: Wed, 28 Sep 2011 17:19:52 -0300 > What about something like below? It will change a bit the > secure_redirects documentation. The previous check was stronger, and served other purposes. Firstly, it required that the spoofer know the exact gateway IP address we used previously, whereas your test requires only knowing the subnet which is easier to figure out. But more importantly, the old test allowed us to ignore outdated or erroneous redirects. We really have to restore the original behavior before my inetpeer changes (enforce that the old gateway matches), and find another way to accomodate IPVS. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: David Miller <davem@davemloft.net> Date: Wed, 28 Sep 2011 18:56:54 -0400 (EDT) > From: Flavio Leitner <fbl@redhat.com> > Date: Wed, 28 Sep 2011 17:19:52 -0300 > >> What about something like below? It will change a bit the >> secure_redirects documentation. > > The previous check was stronger, and served other purposes. > > Firstly, it required that the spoofer know the exact gateway > IP address we used previously, whereas your test requires only > knowing the subnet which is easier to figure out. > > But more importantly, the old test allowed us to ignore outdated > or erroneous redirects. > > We really have to restore the original behavior before my inetpeer > changes (enforce that the old gateway matches), and find another way > to accomodate IPVS. BTW, I just double-checked RFC1122 and it explicitly specifies the old_gw check: [ RFC1122, section 3.2.2.2 ] ... A Redirect message SHOULD be silently discarded if the new gateway address it specifies is not on the same connected (sub-) net through which the Redirect arrived [INTRO:2, Appendix A], or if the source of the Redirect is not the current first-hop gateway for the specified destination (see Section 3.3.1). In fact, it's saying that we should also validate that saddr == old_gw too. So really, we need to put the check back and find a way to accomodate IPVS. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Sep 28, 2011 at 07:12:55PM -0400, David Miller wrote: > From: David Miller <davem@davemloft.net> > Date: Wed, 28 Sep 2011 18:56:54 -0400 (EDT) > > > From: Flavio Leitner <fbl@redhat.com> > > Date: Wed, 28 Sep 2011 17:19:52 -0300 > > > >> What about something like below? It will change a bit the > >> secure_redirects documentation. > > > > The previous check was stronger, and served other purposes. > > > > Firstly, it required that the spoofer know the exact gateway > > IP address we used previously, whereas your test requires only > > knowing the subnet which is easier to figure out. > > > > But more importantly, the old test allowed us to ignore outdated > > or erroneous redirects. > > > > We really have to restore the original behavior before my inetpeer > > changes (enforce that the old gateway matches), and find another way > > to accomodate IPVS. > > BTW, I just double-checked RFC1122 and it explicitly specifies the > old_gw check: > > [ RFC1122, section 3.2.2.2 ] > > ... > > A Redirect message SHOULD be silently discarded if the new > gateway address it specifies is not on the same connected > (sub-) net through which the Redirect arrived [INTRO:2, > Appendix A], or if the source of the Redirect is not the > current first-hop gateway for the specified destination (see > Section 3.3.1). > > In fact, it's saying that we should also validate that saddr == old_gw > too. > > So really, we need to put the check back and find a way to accomodate IPVS. Hi Dave, I'm have to admit that this issues is new to me. But doesn't it affect any setup where a secondary address is being used as the gateway and the gateway send an ICMP redirect? Perhaps an option to weaken the check for these cases would provide a work-around for those who need it. Or does that break your inetpeer changes horribly? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 075212e..fa00fcd 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1332,6 +1332,9 @@ void ip_rt_redirect(__be32 old_gw, __be32 daddr, __be32 new_gw, goto reject_redirect; } + if (IN_DEV_SEC_REDIRECTS(in_dev) && ip_fib_check_default(old_gw, dev)) + goto reject_redirect; + peer = inet_getpeer_v4(daddr, 1); if (peer) { peer->redirect_learned.a4 = new_gw;