netdev - Re: [PATCH net-next] ipv4: introduce ip_dst_mtu_secure and protect forwarding path against pmtu spoofing

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: <20131219121757.GD14429@order.stressinduktion.org>
Date:	Thu, 19 Dec 2013 13:17:57 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	David Miller <davem@...emloft.net>
Cc:	johnwheffner@...il.com, netdev@...r.kernel.org,
	eric.dumazet@...il.com
Subject: Re: [PATCH net-next] ipv4: introduce ip_dst_mtu_secure and protect forwarding path against pmtu spoofing

On Thu, Dec 19, 2013 at 12:12:03AM -0500, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@...essinduktion.org>
> Date: Thu, 19 Dec 2013 01:07:59 +0100
> 
> > On Wed, Dec 18, 2013 at 06:55:13PM -0500, John Heffner wrote:
> >> On using the interface MTU for all forwarded packets, I have a similar
> >> reaction as David.  And why are forwarded packets more special than
> >> local ones, from the routing code's point of view?  It seems like
> >> there could be other ways to harden a router, like firewall rules.
> > 
> > I doubt it is trivial to set up such a filter as we have to inspect
> > the payload of the icmp error. I played with it and it is certainly
> > possible, but my intention was that the networking stack does try to
> > prevent fragmentation and delay generation of fragments to the last
> > router on the path where it is necessary.
> 
> John's more important point is why treat forwarded traffic specially
> from that which is locally generated?

Routers don't receive ICMP frag-needed packets at all for forwarded
traffic but only for locally generated packets. As we can't be very
strict with payload tag checking because we often don't have enough
information from the returned payload, we cannot easily distinguish
between ICMP packets sent because of local traffic or for forwarded
traffic. All frag-needed notifications sent in return of forwarded traffic
are inherently bogus or have a malicious background and should not be
handled.  Becasue we cannot harden the receive handler in all cases,
we need to protect the forwarding path to use such information.

Networking software on the end system which wants to guard against
that kind of fragmentation can do so by using the various knobs to
limit pmtu notification processing or use IP_PMTUDISC_INTERFACE to
protect itself from sending fragments. (Note, all other methods but
IP_PMTUDISC_INTERFACE have impact on all protocols, which could also
break other services on that box). But if one has a linux router without
complex icmp payload checking firewall enabled, the packets send without
DF-bit will get fragmented at the next hops if an attacker managed to
send such a spoofed pmtu notification to that router. They simply need to
traceroute the path. We should avoid that!

It would be great if we could use IP_PMTUDISC_PROBE (so setting DF-flag)
for DNS packets but it could break stuff for sub-dns-max-size mtu links.

Thanks,

  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