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: <20140108061320.GA9007@order.stressinduktion.org>
Date:	Wed, 8 Jan 2014 07:13:20 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, eric.dumazet@...il.com,
	johnwheffner@...il.com, steffen.klassert@...unet.com,
	fweimer@...hat.com
Subject: Re: [PATCH net-next v3 1/3] ipv4: introduce ip_dst_mtu_secure and protect forwarding path against pmtu spoofing

On Wed, Jan 08, 2014 at 01:02:13AM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date: Wed, 8 Jan 2014 06:02:25 +0100
> 
> > Hi David!
> > 
> > On Tue, Jan 07, 2014 at 07:13:14PM -0500, David Miller wrote:
> >> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> >> Date: Mon, 6 Jan 2014 09:48:27 +0100
> >> 
> >> > +ip_forward_use_pmtu - BOOLEAN
> >> > +	By default we don't trust protocol path MTUs while forwarding
> >> > +	because they could be easily forged and can lead to unwanted
> >> > +	fragmentation by the router.
> >> > +	You only need to enable this if you have user-space software
> >> > +	which tries to discover path mtus by itself and depends on the
> >> > +	kernel honoring this information. This is normally not the
> >> > +	case.
> >> > +	Default: 0 (disabled)
> >> > +	Possible values:
> >> > +	0 - disabled
> >> > +	1 - enabled
> >> 
> >> You made this default to off, great, but the description text still says
> >> that we don't trust PMTU information by default :-)
> > 
> > Hm, sorry, but I don't see the contradiction.
> 
> You say "By default we don't trust protocol path MTUs", but if the
> default value of ip_forward_use_pmtu is zero, we in fact do.

I am sorry..  maybe I am just stupid?

static inline unsigned int ip_dst_mtu_secure(const struct dst_entry *dst,
                                            bool forwarding)
{
       struct net *net = dev_net(dst->dev);

       if (net->ipv4.sysctl_ip_fwd_use_pmtu ||
           dst_metric_locked(dst, RTAX_MTU) ||
           !forwarding)
               return dst_mtu(dst);

       return min(dst->dev->mtu, IP_MAX_MTU);
}

The path with dst_mtu is the patch where I want to use the path
mtu information. It only gets reached either by locked route,
sysctl_ip_fwd_use_pmtu not zero or we are not forwarding the packet.

So, if fwd_use_pmtu is zero, either the mtu must be locked or we are
not forwarding the packet to use the path mtu.

Sorry for the confusion,

  Hannes

--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ