Re: Responsible Disclosure

Re: Responsible Disclosure

[D. S. Ljungmark]

[-- Attachment #1.1: Type: text/plain, Size: 2758 bytes --]

On tis, 2015-03-24 at 19:45 +0100, Greg KH wrote:
> On Tue, Mar 24, 2015 at 12:25:39AM +0100, D. S. Ljungmark wrote:
> > On mån, 2015-03-09 at 06:49 +0100, Greg KH wrote:
> > > On Mon, Mar 09, 2015 at 01:45:08AM +0100, D. S. Ljungmark wrote:
> > > > Hi.
> > > >   We have developed a somewhat disturbing DoS attack (due to a logic
> > > > error) that affects _at least_ :
> > > > 
> > > >   Windows 8.1 (32bit) 
> > > >   Mac OS X  10.10
> > > >   FreeBSD 10.1
> > > >   Linux 3.x (samples between 3.0 => 3.18 tested)
> > > >   Android  (Lollipop) 
> > > > 
> > > > Now, we have a problem with reporting this, in that it doesn't only
> > > > apply to a single OS/implementation. 
> > > >   
> > > > The mitigation is fairly simple ( in lines of code ) and we have a patch
> > > > for Linux already. 
> > > > 
> > > > There is a working proof of concept, and the cause might be attributed
> > > > to a somewhat naive interpretation / concept in an IETF RFC, that has
> > > > since been amended, but not fixed in implementations.
> > > > 
> > > > 
> > > > I am not going to dump this as a bombshell by dropping it on Slashdot or
> > > > similar and watching the fallout as many of the worlds shared hosting
> > > > services drop offline from malicious usage. 
> > > > 
> > > > On the other hand, I'm not going to give certain parts prior knowledge
> > > > with example PoC just because they feel privileged and want to delay
> > > > this for unreasonable amounts of time.  We're all adults here, and know
> > > > how to communicate this.
> > > > 
> > > > Who can organize a coherent Review / Analysis / Patch / Disclosure of
> > > > this? Where do I start? Who do I contact? 
> > > > 
> > > > We're trying to do the right thing here, but there isn't much documented
> > > > on how to report cross-platform bugs that has the possibility of causing
> > > > larger breakage.
> > > 
> > > The linux-distros mailing list is your best bet.  They replaced the old
> > > vendor-sec mailing list.  They can help you out here with notifying
> > > everyone involved and generating a fix properly.
> > > 
> > > Hope this helps,
> > > 
> > > greg k-h
> > 
> > 
> > Following up with the patch, got an okay from CERT to post it.
> > 
> > Signed-Off-By: D.S. Ljungmark <ljungmark@modio.se>
> 
> What patch?  I didn't see anything here :(
> 
> Did you sent it to netdev@vger.kernel.org?
> 
> If not, can you please do so, that way the kernel networking developers
> can see it and apply it.
> 
> thanks,
> 
> greg k-h

This patch prevents a link-local DoS against ipv6. 


To exploit, push an RA packet without any routing information, but with
the hop limit reduced to 1.

//D.S. Ljungmark







[-- Attachment #1.2: linux-3.18-ipv6-hop_limit.patch --]
[-- Type: text/x-patch, Size: 897 bytes --]

diff -urw linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c
--- linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c	2015-03-08 13:01:36.567000000 -0400
+++ linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c	2015-03-08 12:50:55.446000000 -0400
@@ -1215,7 +1215,15 @@
 	if (rt)
 		rt6_set_expires(rt, jiffies + (HZ * lifetime));
 	if (ra_msg->icmph.icmp6_hop_limit) {
+		/*
+		 *	Only set hop_limit on the interface if it is higher than the current hop_limit.
+		 *	Prevents silly routes with hop_limit 1 from affecting everyone.
+		 */
+		if (in6_dev->cnf.hop_limit < ra_msg->icmph.icmp6_hop_limit) {
 		in6_dev->cnf.hop_limit = ra_msg->icmph.icmp6_hop_limit;
+		} else {
+			ND_PRINTK(2, warn, "RA: Got route advertisement with lower hop_limit than current\n");
+		}
 		if (rt)
 			dst_metric_set(&rt->dst, RTAX_HOPLIMIT,
 				       ra_msg->icmph.icmp6_hop_limit);

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Responsible Disclosure

[Greg KH]

On Tue, Mar 24, 2015 at 08:31:01PM +0100, D. S. Ljungmark wrote:
> 
> This patch prevents a link-local DoS against ipv6. 
> 
> 
> To exploit, push an RA packet without any routing information, but with
> the hop limit reduced to 1.
> 
> //D.S. Ljungmark
> 
> 
> 
> 
> 
> 

> diff -urw linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c
> --- linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c	2015-03-08 13:01:36.567000000 -0400
> +++ linux-3.18.7-200.fc21.x86_64/net/ipv6/ndisc.c	2015-03-08 12:50:55.446000000 -0400
> @@ -1215,7 +1215,15 @@
>  	if (rt)
>  		rt6_set_expires(rt, jiffies + (HZ * lifetime));
>  	if (ra_msg->icmph.icmp6_hop_limit) {
> +		/*
> +		 *	Only set hop_limit on the interface if it is higher than the current hop_limit.
> +		 *	Prevents silly routes with hop_limit 1 from affecting everyone.
> +		 */
> +		if (in6_dev->cnf.hop_limit < ra_msg->icmph.icmp6_hop_limit) {
>  		in6_dev->cnf.hop_limit = ra_msg->icmph.icmp6_hop_limit;
> +		} else {
> +			ND_PRINTK(2, warn, "RA: Got route advertisement with lower hop_limit than current\n");
> +		}
>  		if (rt)
>  			dst_metric_set(&rt->dst, RTAX_HOPLIMIT,
>  				       ra_msg->icmph.icmp6_hop_limit);


Please submit this in a form that can be applied.

Take a look at Documentation/SubmittingPatches for the proper format.

Also, you are messing with the coding style here for no reason (hint,
indent after the if, and wrap your lines properly.)

Can you fix that up, and resend, starting a new email thread, netdev
doesn't care about the prior subject, you need to pick a proper one for
the patch.

thanks,

greg k-h

Re: Responsible Disclosure

[Hannes Frederic Sowa]

On Tue, Mar 24, 2015, at 20:55, Greg KH wrote:
> Please submit this in a form that can be applied.
> 
> Take a look at Documentation/SubmittingPatches for the proper format.
> 
> Also, you are messing with the coding style here for no reason (hint,
> indent after the if, and wrap your lines properly.)
> 
> Can you fix that up, and resend, starting a new email thread, netdev
> doesn't care about the prior subject, you need to pick a proper one for
> the patch.

Please also refer to the section where IETF did reconsider this issue.

Thanks,
Hannes