netdev - Re: minimum ICMPv6 message size vs. RPL's DIS

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Fri, 26 Jul 2013 01:31:34 +0200
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Werner Almesberger <werner@...esberger.net>
Cc:	netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: minimum ICMPv6 message size vs. RPL's DIS

On Thu, Jul 25, 2013 at 06:47:49PM -0300, Werner Almesberger wrote:
> Hannes Frederic Sowa wrote:
> > I don't know how they could do this if they want to let other RFCs extend
> > icmp types.
> 
> Oh, ICMPs can have padding. That's used to enforce "nice" alignment.
> Even RFC 6550 (RPL) has that. For example, you could simply pad the
> troublesome DIS, message which is
> 
> Offset	Value	Description
> ------	-----	------------------------------------------------
> 0	0x9b	ICMPv6 Type = RPL (155, section 6)
> 1	0x00	ICMPv6 Code = DODAG Information Solicitation (0)
> 2	0x??	Checksum
> 3	0x??	(continued)
> 
> 4	0x00	Flags = 0 (section 6.2.1)
> 5	0x00	Reserved
> 
> to eight bytes (i.e., four bytes of body) by adding
> 
> 6	0x01	Option Type = PadN (section 6.7.3)
> 7	0x00	Option Length = 0
> 
> But if nothing obliges the sender to do so, there's no excuse for
> Linux to expect such padding.

Yes, of course, that's possible but not specified at all in the general
ICMPv6 RFC.  If packets are too short for some medium, I guess, one
would stretch it with extension header paddings before the icmpv6 header.

> > Yes, that could be an issue. I would be willing to accept this fallout. :)
> 
> I'm kinda curious what sort of policy we have on that. The worst
> case would be that there's a bunch of 64 bit Linux machines out
> there, doing critical infrastructure things in the Internet (not an
> unlikely role, given the API in question), and their user space has
> some vulnerability if the kernel lets a "short" ICMPv6 packet
> through.

You forgot one critical aspect: Important infrastructure is *never*
going to be updated and definitely never runs IPv6. ;)

I don't think there is a policy, just intuition.

> Of course, "The Almesberger-Sowa Internet Meltdown of 2013" does
> have a nice ring to it, in an apocalyptic kind of way ...

I would like to avoid such a scenario, but have seen enough patches that
I kind of cooled down a bit. ;)

In summary, I agree, we should get both changes at once into the tree or
none (of course I would still change the pointer to something reasonable
and describe the circumstances in a comment if we don't change the
current behaviour).

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