netdev - Re: [PATCH net-next 0/6] net: Call skb_get

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: <1425578372.5130.250.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Thu, 05 Mar 2015 09:59:32 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Tom Herbert <therbert@...gle.com>
Cc:	David Laight <David.Laight@...lab.com>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"fw@...len.de" <fw@...len.de>
Subject: Re: [PATCH net-next 0/6] net: Call skb_get_hash in qdiscs

On Thu, 2015-03-05 at 09:19 -0800, Tom Herbert wrote:

> Probably a little closer to 1/50. But this is the best case scenario
> that assumes a completely random input. In reality the input could be
> heavily biased substantially increasing collisions. Consider if
> we're in the forwarding path for two NVEs tunneling using VXLAN.
> Encapsulated flows will differ in flow_keys only in source port with
> 14 bits of entropy. Now with 100 flows collision probability is 1/25,
> at at 1000 flows you're pretty much guaranteed collisions. In such a
> scenario, any amount of perturbation, re-keying of hashes, even
> switching to more fancy hash algorithms doesn't help-- the root
> problem is that the input domain does not contain sufficient entropy.
> 
> This is not just a performance issue, this is an obvious security
> issue. It's fairly easy to DOS 5-tuples at will by spoofing packets
> with different 5-tuples. This is absolutely trivial with IPv6. Given
> we want to DOS a TCP connection with four tuple <S,D,s,d> and source
> address is of form w::x:y, we can just change to the source address to
> be w::x^J:y:^J and copy rest of the four-tuple. For any J this creates
> same src value in flow_keys as w::x:y, hence always the same hash.
> There are similar ways to spoof 4-tuple with IPv4 tunnels like the
> VXLAN case above.
> 
> So if we want to fix this, we need to address the limited information
> used in flow_keys. 1) flow_keys needs more information such as full
> IPv6 address, VLAN, GRE keyid, and flow label. 2) We need a hash
> function that can take more bits of flow_kesy as input to avoid the
> aliasing problems like we see with the IPv6 case. This is where I am
> going with these patches.

I thought we added ipv6_addr_jhash() for these reasons ?

If you believe this issue is pressing, just change 

flow->src = (__force __be32)ipv6_addr_hash(&iph->saddr);
flow->dst = (__force __be32)ipv6_addr_hash(&iph->daddr);

to use ipv6_addr_jhash()

Note: So far, rxhash never has been a security issue.



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