netdev - Re: [PATCH] ipv6: set accept_ra_rt_info_max

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20140320020238.GK12291@order.stressinduktion.org>
Date:	Thu, 20 Mar 2014 03:02:38 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Jiri Bohac <jbohac@...e.cz>
Cc:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: set accept_ra_rt_info_max_plen to 128 by default

On Wed, Mar 19, 2014 at 06:22:10PM +0100, Jiri Bohac wrote:
> I have been looking for the reason behind the default of
> accept_ra_rt_info_max_plen being 0. No luck.
> 
> The feature has been introduced by 09c884d4 ([IPV6]: ROUTE: Add
> accept_ra_rt_info_max_plen sysctl).
> 
> The only relevant discussion I found was
> http://markmail.org/message/5m34bfzhox6y5lcf
> with no explanation.
> 
> I imagine that the motivation for setting
> accept_ra_rt_info_max_plen to 0 would be security concerns.
> 
> However, RFC 4191, section "6. Security Consideration", concludes
> that the new features don't increase the risks already present:
> 
> 	A malicious node could send Router Advertisement messages, specifying
> 	a High Default Router Preference or carrying specific routes, with
> 	the effect of pulling traffic away from legitimate routers.  However,
> 	a malicious node could easily achieve this same effect in other ways.
> 
> 	For example, it could fabricate Router Advertisement messages with a
> 	zero Router Lifetime from the other routers, causing hosts to stop
> 	using the other routes.  By advertising a specific prefix, this
> 	attack could be carried out in a less noticeable way.  However, this
> 	attack has no significant incremental impact on Internet
> 	infrastructure security.
> 
> Sounds reasonable to me.
> 
> Also, RFC 6434 has been published since, and under 5.3. it says:
> 
> 	Small Office/Home Office (SOHO) deployments supported by routers
> 	adhering to [RFC6204] use RFC 4191 to advertise routes to certain
> 	local destinations.  Consequently, nodes that will be deployed in
> 	SOHO environments SHOULD implement RFC 4191.
> 

My concern with the kernel adding arbitrary length prefix routes to
the routing table is, that this could enable attacks on VPN software
by advertising smaller prefixes thus still leaving basic connectivity
intact but rerouting VPN internal traffic around the VPN tunnel because
of the more specific lookup.

Sure, this also is a problem for DHCP/IPv4 setups, but that is a concern
of userspace. ;)

I am totally fine with your reasoning and don't know what the initial
motivation for the default setting was, but I am a bit hesitant about
this change.

Greetings,

  Hannes

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