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
| ||
|
Date: Mon, 6 Apr 2015 21:45:45 -0700 From: Tom Herbert <tom@...bertland.com> To: David Miller <davem@...emloft.net> Cc: netdev@...r.kernel.org, netfilter-devel@...r.kernel.org, pablo@...filter.org, hannes@...essinduktion.org, Jiří Pírko <jiri@...nulli.us> Subject: Re: [PATCH 0/4] Prevent UDP tunnels from operating on garbage socket On Mon, Apr 6, 2015 at 8:51 PM, David Miller <davem@...emloft.net> wrote: > From: Tom Herbert <tom@...bertland.com> > Date: Mon, 6 Apr 2015 19:43:11 -0700 > >> To be honest, requiring an additional socket to transmit UDP >> encapsulation seems really convoluted to me, especially considering >> that this is just trying trying to solve AF_PACKET in nf which seems >> like a narrow use case. Is there no way to test for AF_PACKET sockets >> and take action at a lower function? Does every type encapsulation >> need its own UDP socket, or can you just have one which set from the >> udp_tunnel when family of skb->sk is AF_PACKET? > > This has nothing to do with netfilter. > > This has everything to do with being able to pass a socket down > through the complete ipv4/ipv6 output path. That's the only > reason netfilter needed to be touched. > > The ipv4/ipv6 output call paths have the NF hooks in the middle, and > the NF hooks determine what the call signature is for the rest of the > output path. That's why it needed to be adjusted. > > For ipv6 fragmentation, in particular, having the right ipv4/ipv6 > socket is going to be important. > > AF_PACKET is not an isolated case, just the most likely example. It's > just as easy to trigger this problem for other protocol families too. > You can send appletalk packets over VXLAN. > > I don't see what is convoluted about using the correct socket for > sending L3 protocol frames. That's in fact how it's _supposed_ to > work. And consistently having a proper matching socket available > makes it so that, long-term, we'll never have to deal with this issue > ever again. I guess this is where I'm confused. We can send just about anything over GRE also, but have never needed a transmit socket for that. Is UDP encapsulation so different, or is GRE equally broken also? Also, will we need to add the socket to FOU and GUE then? Thanks, Tom -- 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