oss-security - Re: Linux kernel handling of IPv6 temporary addresses

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Wed, 16 Jan 2013 13:58:10 +0200
From: George Kargiotakis <kargig@...d.gr>
To: P J P <ppandit@...hat.com>, oss-security@...ts.openwall.com
Subject: Re: Linux kernel handling of IPv6 temporary
 addresses

Hello,

You can reproduce the bug with a new option for flood_router26 that has been added to the thc-ipv6 toolkit v2.1.
# ./flood_router26 -A eth0

I've applied your patch to 3.5.7 and unless I've done something wrong, it doesn't seem to work. Actually I can't
get any temporary address assignment with it. This is what I get upon booting with your patch:

[   35.045299] sky2 0000:01:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both
[   35.045765] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   36.985436] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached
[   36.985474] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached
[   63.204196] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached
[   63.204241] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached
[   86.125990] Netfilter messages via NETLINK v0.30.
[   86.883815] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached
[   86.883850] IPv6: ipv6_create_tempaddr: ipv6 temporary address upper limit reached
[  114.611839] IPv6: ipv6_create_tempaddr: regeneration time exceeded - disabled temporary address support

# cat /proc/sys/net/ipv6/conf/eth0/use_tempaddr 
-1

As I've already said to Eric Dumazet who's also been trying to provide a patch for the issue
I think that the correct way to resolve the issue would be to follow the recommendations of 
draft-gont-opsec-ipv6-nd-security-00 section 3.6.4
<quote>
   Even if hosts do enforce a limit on the number of IPv6 addresses
   configured, an attacker might try to cause victim hosts to ignore
   legitimate prefixes previously advertised for address configuration
   by legitimate routers.  Hereby we recommend hosts to not discard
   previously configured addresses if new prefixes for address auto-
   configuration are advertised and the limit for the maximum number of
   configured addresses (per interface) has been reached.  When such
   limit is hit, the newly advertised prefixes for address auto-
   configuration should be ignored.
</quote>

Best Regards,

P.S. please CC me in your answers
-- 
George Kargiotakis
https://void.gr
GPG KeyID: 0xE4F4FFE6
GPG Fingerprint: 9EB8 31BE C618 07CE 1B51 818D 4A0A 1BC8 E4F4 FFE6

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.