ipv6: do not disable temp_address when reaching max_address
Subsystems (3)
PATCH v2 1/3 ipv6: do not disable temp_address when reaching max_address
A LAN user can remotely disable temporary address which may lead to privacy violatins and information disclosure.
The reason is that the linux kernel uses the 'ipv6.max_addresses' option to specify how many ipv6 addresses and interface may have. The 'ipv6.regen_max_retry' (default value 3) option specifies how many times the kernel will try to create a new address.
But the kernel is not distinguish between the event of reaching max_addresses for an interface and failing to generate a new address. the kernel disable the temporary address after regenerate a new address 'regen_max_retry' times.
According RFC4941 3.3.7:
---------------------------------------
If DAD indicates the address is already in use,
the node must generate a new randomized interface
identifier as described in section 3.2 above, and
repeat the previous steps as appropriate up toTEMP_IDGEN_RETRIES times.
If after TEMP_IDGEN_RETRIES consecutive attempts no non-unique address was generated, the node must log a system error and must not attempt to generate temporary address for that interface.
------------------------------------------
RFC4941 3.3.7 specifies that disabling the temp_address must happen upon the address is already in use, not reach the max_address, So we have to check the return err and distinguish the correct retry path.
This fixes CVE-2013-0343
--- net/ipv6/addrconf.c | 25 +++++++++++++++++++++---- 1 file changed, 21 insertions(+), 4 deletions(-)
net/ipv6/addrconf.c +21 -4
@@ -1134,10 +1134,27 @@ retry:if (IS_ERR_OR_NULL (ift)) {in6_ifa_put (ifp);in6_dev_put (idev); -pr_info ("%s: retry temporary address regeneration\n" , __func__); - tmpaddr = &addr; -write_lock (&idev->lock); - goto retry; + +/* According RFC4941 3.3.7: +* If DAD indicates the address is already in use, +* the node must generate a new randomized interface +* identifier as described in section 3.2 above, and +* repeat the previous steps as appropriate up to +* TEMP_IDGEN_RETRIES times. +* If after TEMP_IDGEN_RETRIES consecutive attempts no +* non-unique address was generated, the node must log +* a system error and must not attempt to generate +* temporary address for that interface. +* So we have to check the return err and distinguish +* the correct retry path. +*/ +if (PTR_ERR (ift) == -EEXIST ) { +pr_info ("%s: retry temporary address regeneration\n" , __func__); + tmpaddr = &addr; +write_lock (&idev->lock); + goto retry; + }else + goto out; }spin_lock_bh (&ift->lock);
Signature · 1 line
1.8.2.1
Quoted 23 lines · Ding Tianhong
net/ipv6/addrconf.c +11
-4@@ -1134,10 +1134,27 @@ retry:if (IS_ERR_OR_NULL (ift)) {in6_ifa_put (ifp);in6_dev_put (idev); -pr_info ("%s: retry temporary address regeneration\n" , __func__); - tmpaddr = &addr; -write_lock (&idev->lock); - goto retry; + +/* According RFC4941 3.3.7: +* If DAD indicates the address is already in use, +* the node must generate a new randomized interface +* identifier as described in section 3.2 above, and +* repeat the previous steps as appropriate up to +* TEMP_IDGEN_RETRIES times. +* If after TEMP_IDGEN_RETRIES consecutive attempts no +* non-unique address was generated, the node must log +* a system error and must not attempt to generate +* temporary address for that interface.
net/ipv6/addrconf.c retry: · line 1157
Quoted 10 lines
net/ipv6/addrconf.c +10
-0+* So we have to check the return err and distinguish +* the correct retry path. +*/ +if (PTR_ERR (ift) == -EEXIST ) { +pr_info ("%s: retry temporary address regeneration\n" , __func__); + tmpaddr = &addr; +write_lock (&idev->lock); + goto retry; + }else + goto out;
Correct me if I am wrong, but the RFC referes by mentioning "in use" to allocated on the subnet and not in use by this host. I don't see how this fixes the CVE then. dad is triggered by ipv6_add_addr.
Greetings,
Hannes
Quoted 30 lines · Hannes Frederic Sowa
Quoted 29 lines · Ding Tianhong
net/ipv6/addrconf.c +17
-4@@ -1134,10 +1134,27 @@ retry:if (IS_ERR_OR_NULL (ift)) {in6_ifa_put (ifp);in6_dev_put (idev); -pr_info ("%s: retry temporary address regeneration\n" , __func__); - tmpaddr = &addr; -write_lock (&idev->lock); - goto retry; + +/* According RFC4941 3.3.7: +* If DAD indicates the address is already in use, +* the node must generate a new randomized interface +* identifier as described in section 3.2 above, and +* repeat the previous steps as appropriate up to +* TEMP_IDGEN_RETRIES times. +* If after TEMP_IDGEN_RETRIES consecutive attempts no +* non-unique address was generated, the node must log +* a system error and must not attempt to generate +* temporary address for that interface. +* So we have to check the return err and distinguish +* the correct retry path. +*/ +if (PTR_ERR (ift) == -EEXIST ) { +pr_info ("%s: retry temporary address regeneration\n" , __func__); + tmpaddr = &addr;
Quoted 8 lines
net/ipv6/addrconf.c retry: · line 1157
Quoted 4 lines
net/ipv6/addrconf.c +4
-0+write_lock (&idev->lock); + goto retry; + }else + goto out;Correct me if I am wrong, but the RFC referes by mentioning "in use" to allocated on the subnet and not in use by this host. I don't see how this fixes the CVE then. dad is triggered by
ipv6_add_addr.
Eric already posted a proposal. It seems it lacked testing. Maybe you could start from this?
http://permalink.gmane.org/gmane.linux.network/253518
Thanks for looking into this,
Hannes
Quoted 40 lines · Hannes Frederic Sowa
Quoted 30 lines · Hannes Frederic Sowa
Quoted 29 lines · Ding Tianhong
net/ipv6/addrconf.c +17
-4@@ -1134,10 +1134,27 @@ retry:if (IS_ERR_OR_NULL (ift)) {in6_ifa_put (ifp);in6_dev_put (idev); -pr_info ("%s: retry temporary address regeneration\n" , __func__); - tmpaddr = &addr; -write_lock (&idev->lock); - goto retry; + +/* According RFC4941 3.3.7: +* If DAD indicates the address is already in use, +* the node must generate a new randomized interface +* identifier as described in section 3.2 above, and +* repeat the previous steps as appropriate up to +* TEMP_IDGEN_RETRIES times. +* If after TEMP_IDGEN_RETRIES consecutive attempts no +* non-unique address was generated, the node must log +* a system error and must not attempt to generate +* temporary address for that interface. +* So we have to check the return err and distinguish +* the correct retry path. +*/ +if (PTR_ERR (ift) == -EEXIST ) { +pr_info ("%s: retry temporary address regeneration\n" , __func__); + tmpaddr = &addr;Quoted 8 lines
net/ipv6/addrconf.c retry: · line 1157
Quoted 4 lines
net/ipv6/addrconf.c +4
-0+write_lock (&idev->lock); + goto retry; + }else + goto out;Correct me if I am wrong, but the RFC referes by mentioning "in use" to allocated on the subnet and not in use by this host. I don't see how this fixes the CVE then. dad is triggered by
ipv6_add_addr.
Quoted 9 lines
Eric already posted a proposal. It seems it lacked testing. Maybe you could start from this?
http://permalink.gmane.org/gmane.linux.network/253518
Thanks for looking into this,
Hannes
the patch could not solve the problem, the use_tempaddr will still be -1 after the attack.
Quoted 7 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html.
Quoted 39 lines · Hannes Frederic Sowa
Quoted 23 lines · Ding Tianhong
net/ipv6/addrconf.c +11
-4@@ -1134,10 +1134,27 @@ retry:if (IS_ERR_OR_NULL (ift)) {in6_ifa_put (ifp);in6_dev_put (idev); -pr_info ("%s: retry temporary address regeneration\n" , __func__); - tmpaddr = &addr; -write_lock (&idev->lock); - goto retry; + +/* According RFC4941 3.3.7: +* If DAD indicates the address is already in use, +* the node must generate a new randomized interface +* identifier as described in section 3.2 above, and +* repeat the previous steps as appropriate up to +* TEMP_IDGEN_RETRIES times. +* If after TEMP_IDGEN_RETRIES consecutive attempts no +* non-unique address was generated, the node must log +* a system error and must not attempt to generate +* temporary address for that interface. net/ipv6/addrconf.c retry: · line 1157
Quoted 10 lines
net/ipv6/addrconf.c +10
-0+* So we have to check the return err and distinguish +* the correct retry path. +*/ +if (PTR_ERR (ift) == -EEXIST ) { +pr_info ("%s: retry temporary address regeneration\n" , __func__); + tmpaddr = &addr; +write_lock (&idev->lock); + goto retry; + }else + goto out;Correct me if I am wrong, but the RFC referes by mentioning "in use" to allocated on the subnet and not in use by this host. I don't see how this fixes the CVE then. dad is triggered by
ipv6_add_addr.
Quoted 4 lines
Greetings,
Hannes
Reference:
-> http://seclists.org/oss-sec/2012/q4/292
-> http://seclists.org/oss-sec/2013/q1/92
I think the point is after the ./flood_route26 attack,
the proc/sys/net/ipv6/conf/iface/use_tempaddr will change from 2 to -1, whether is correct? :)
regards
Ding Tianhong
Quoted 7 lines
--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html.