Re: Responsible Disclosure

["D. S. Ljungmark" <spider@takeit.se>]

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