netdev - Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only padding

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 7 Sep 2013 23:34:45 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	Eldad Zack <eldad@...refinery.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, kuznet@....inr.ac.ru,
	jmorris@...ei.org, yoshfuji@...ux-ipv6.org, kaber@...sh.net
Subject: Re: [patch net/stable] ipv6/exthdrs: accept tlv which includes only
 padding

Sat, Sep 07, 2013 at 06:46:12PM CEST, eldad@...refinery.com wrote:
>
>
>On Sat, 7 Sep 2013, Jiri Pirko wrote:
>
>> Sat, Sep 07, 2013 at 02:31:36PM CEST, eldad@...refinery.com wrote:
>> >
>> >Hi Jiri,
>> >
>> >On Fri, 6 Sep 2013, Jiri Pirko wrote:
>> >
>> >> In rfc4942 and rfc2460 I cannot find anything which would implicate to
>> >> drop packets which have only padding in tlv.
>> >
>> >NAK from my side.
>> >Please read RFC4942 2.1.9.5 "Misuse of Pad1 and PadN Options".
>> 
>> I did.
>> 
>> >
>> >While it doesn't specifically discusses this corner case, you can 
>> >understand from "There is no legitimate reason for padding beyond the 
>> >next eight octet..." that there's also no legitimate reason for an 
>> >option header containing only padding.
>> 
>> Okay. I'm glad you agree with me and that we both understand the rfc the
>> same way. And since the rfc does not say that "here's no legitimate
>> reason for an option header containing only padding", this should be
>> possible. I say we respect rfc and do not add stronger restrictions than
>> it dictates. No need for them.
>
>Strictly speaking, this RFC is informational, so it is doesn't dictate 
>per se. I hope you don't suggest removing the other checks as well...

If there are some that just plainly assumes something and does
restrictions without any solid argument, yes remove them.

>
>> >I can't imagine a sane use-case for this.
>> 
>> rfcs are not about sanity...
>
>Great, we're in agreement again :) But I think the networking code is 
>or should be.
>What IPv6 stack would generate such a packet, given that the only usage 
>of the padding options is to align other options?

But why not? I do not see anything evil about that. And rfc allows it.

>Why should I accept a packet which is most likely an artificially 
>crafted packet (RFC 3514)?
>
>Cheers,
>Eldad
>
--
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