From patchwork Tue Mar 24 19:31:01 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "D. S. Ljungmark" X-Patchwork-Id: 453995 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id E623814012C for ; Wed, 25 Mar 2015 06:31:18 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753598AbbCXTbO (ORCPT ); Tue, 24 Mar 2015 15:31:14 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:32994 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752362AbbCXTbM (ORCPT ); Tue, 24 Mar 2015 15:31:12 -0400 Received: by lbcmq2 with SMTP id mq2so2266716lbc.0 for ; Tue, 24 Mar 2015 12:31:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:cc:date :in-reply-to:references:organization:content-type:mime-version; bh=CC465jVB0WtH58kDALSh3q1vXgqD2H/aVn7OGsztXGA=; b=TJ6pnhicaOmRG3uS3jvHO2iai96tW+PauLNH3iWXu+TjUGyqGhdRxuaz4MJAVH3tBK zptpu2Qr3W0xHjxgemSgJSBJZvtzy9FjHgsLZ+q0WuOd86w1bnDQZkyf6UUi0LEO/DVW s4QrFcEnXuNludqNykNk0xMhkzmc4CodtAus1/VEqjCrEnKctljUTfaJiVkRfuc0Rqqw aHkgLLT8iNPZK8urCSu9whmoiIIw5J+rJXGNHBFU1UX8NIBLp3W0ImSLW+f8FXxHCvL1 Uwdp56eALf0z5J1Lg/4VnV2WthCLd3XWH/ErUBMBKD/ItUf7zAiZzBYN7eM6jY6sa0O9 qqAg== X-Gm-Message-State: ALoCoQnQ/DOXLAMNE2nBIpv4o4gqFt7Wvkcgh1lL/oRyks0Q6rPEnt1LfD5IVPOKA+4SasTvWwFc X-Received: by 10.152.7.212 with SMTP id l20mr5195411laa.68.1427225470464; Tue, 24 Mar 2015 12:31:10 -0700 (PDT) Received: from waves.skuggor.se ([2001:470:ddd2:1::4f9]) by mx.google.com with ESMTPSA id cf1sm44669lbb.19.2015.03.24.12.31.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2015 12:31:08 -0700 (PDT) Message-ID: <1427225461.3276.1.camel@takeit.se> Subject: Re: Responsible Disclosure From: "D. S. Ljungmark" Reply-To: ljungmark@modio.se To: Greg KH Cc: ljungmark@modio.se, "security@kernel.org" , security , netdev@vger.kernel.org Date: Tue, 24 Mar 2015 20:31:01 +0100 In-Reply-To: <20150324184517.GA24177@kroah.com> References: <1425861908.8414.12.camel@modio.se> <20150309054916.GA8575@kroah.com> <1427153139.14059.2.camel@takeit.se> <20150324184517.GA24177@kroah.com> Organization: Modio AB X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 > > 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 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);