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
| ||
|
Message-ID: <alpine.DEB.2.00.1003251028580.21825@blackhole.kfki.hu> Date: Thu, 25 Mar 2010 11:07:55 +0100 (CET) From: Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu> To: Shan Wei <shanwei@...fujitsu.com> cc: Pascal Hambourg <pascal.mail@...uf.fr.eu.org>, YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>, Patrick McHardy <kaber@...sh.net>, David Miller <davem@...emloft.net>, Alexey Dobriyan <adobriyan@...il.com>, Yasuyuki KOZAKAI <yasuyuki.kozakai@...hiba.co.jp>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, netfilter-devel@...r.kernel.org Subject: Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment On Thu, 25 Mar 2010, Shan Wei wrote: > Pascal Hambourg wrote, at 03/25/2010 04:38 PM: > > > > Jozsef Kadlecsik a ?crit : > >> On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote: > >> > >>>> In this case without conntrack, IPv6 would send an ICMPv6 message, > >>>> so in my opinion the transparent thing to do would be to still send > >>>> them. Of course only if reassembly is done on an end host. > >>> Well, no. conntrack should just forward even uncompleted fragments > >>> to next process (e.g. core ipv6 code), and then the core would send > >>> ICMP error back. ICMP should be sent by the core ipv6 code according > >>> to decision of itself, not according to netfilter. > >> But what state could be associated by conntrack to the uncompleted > >> fragments but the INVALID state? In consequence, in any sane setup, the > >> uncompleted fragments will be dropped silently by a filter table rule > >> and no ICMP error message will be sent back. > > > > AFAIK, in the IPv4 stack the reassembly takes place before the INPUT > > chains (NF_IP_LOCAL_IN hook). Is it different in the IPv6 stack ? > > Yes, they are different. > > In IPv4 stack?for an end host, ip_local_deliver() reassemble > fragments before LOCAL_IN hook . > > But in IPv6 stack, ip6_input_finish() handles fragment extension headers > and try to reassemble them *after* LOCAL_IN hook. But we are discussing netfilter and (de)fragmentation: what should happen when the packet reassembly in netfilter times out and the destination is the host itself. In IPv4 the very first subsystem is ipv4_conntrack_defrag, called from NF_INET_PRE_ROUTING. Then comes the raw table and after that conntrack. In IPv6 the very first is the raw table, then comes ipv6_defrag and then conntrack. Why the order of the raw table and defragmentation is reversed for IPv6? That makes impossible to use the NOTRACK target in IPv6: for example if someone enters ip6tables -t raw -A PREROUTING -p tcp --dport 80 -j NOTRACK and if we receive fragmented packets then the first fragment will be untracked and thus skip nf_ct_frag6_gather (and conntrack), while all subsequent fragments enter nf_ct_frag6_gather and reassembly will never successfully be finished. IMHO this is a bug and should be fixed. Patrick, please consider applying the patch below. Singed-off-by: Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu> diff --git a/include/linux/netfilter_ipv6.h b/include/linux/netfilter_ipv6.h index d654873..1f7e300 100644 --- a/include/linux/netfilter_ipv6.h +++ b/include/linux/netfilter_ipv6.h @@ -59,6 +59,7 @@ enum nf_ip6_hook_priorities { NF_IP6_PRI_FIRST = INT_MIN, NF_IP6_PRI_CONNTRACK_DEFRAG = -400, + NF_IP6_PRI_RAW = -300, NF_IP6_PRI_SELINUX_FIRST = -225, NF_IP6_PRI_CONNTRACK = -200, NF_IP6_PRI_MANGLE = -150, diff --git a/net/ipv6/netfilter/ip6table_raw.c b/net/ipv6/netfilter/ip6table_raw.c index ed1a118..3d8c6f0 100644 --- a/net/ipv6/netfilter/ip6table_raw.c +++ b/net/ipv6/netfilter/ip6table_raw.c @@ -70,14 +70,14 @@ static struct nf_hook_ops ip6t_ops[] __read_mostly = { .hook = ip6t_pre_routing_hook, .pf = NFPROTO_IPV6, .hooknum = NF_INET_PRE_ROUTING, - .priority = NF_IP6_PRI_FIRST, + .priority = NF_IP6_PRI_RAW, .owner = THIS_MODULE, }, { .hook = ip6t_local_out_hook, .pf = NFPROTO_IPV6, .hooknum = NF_INET_LOCAL_OUT, - .priority = NF_IP6_PRI_FIRST, + .priority = NF_IP6_PRI_RAW, .owner = THIS_MODULE, }, }; Best regards, Jozsef - E-mail : kadlec@...ckhole.kfki.hu, kadlec@...l.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- 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