* Re: Responsible Disclosure
[not found] ` <20150324184517.GA24177@kroah.com>
@ 2015-03-24 19:31 ` D. S. Ljungmark
2015-03-24 19:55 ` Greg KH
0 siblings, 1 reply; 3+ messages in thread
From: D. S. Ljungmark @ 2015-03-24 19:31 UTC (permalink / raw)
To: Greg KH; +Cc: ljungmark, security@kernel.org, security, netdev
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread