Re: [Cellar] Security considerations: recursive elements

[Steve Lhomme <[e-mail]>]

(starting to reply from the bottom of the thread)

2018-01-18 18:53 GMT+01:00 Michael Bradshaw <[e-mail]>:
> On Wed, Jan 17, 2018 at 11:42 PM, Jerome Martinez <[e-mail]>
> wrote:
>>
>> I missed the case of recursive elements, specified in EBML.
>> for a security section, I don't think that talking about a parser is right
>
>
> The current EBML specification's Security Consideration section contains a
> bulleted list for "Attacks on an EBML Reader" (where an "EBML Reader" is
> explicitly defined as a "data parser[...]"). So if we shouldn't be talking
> about security considerations for parsers, then that whole bulleted list
> should be removed (which I'm opposed to doing). Perhaps I've misunderstood
> your point here, though.

I agree with Michael, this is a legitimate attack and it should be
mentioned. Putting limits is a different topic that would probably go
in a different section of the specs.

>> I am more in favor of  something like "it is possible to have unlimited
>> recursion, potential source of denial of service attacks" in security
>> section and
>> "An implementation may set limits on the maximum depth of nesting" in a
>> parser section (similar to JSON RFC).
>
>
> My apologies if my previous communications have been unclear, but this is
> actually what I'm trying to advocate for, so I think we might agree more
> than we realize. While I have been suggesting including minimum/maximum
> levels, I think that using something like you've written here (and
> completely omitting minimum/maximums) would still be a great improvement.
>
> I do think that also including some kind of minimum/maximum levels could be
> useful. I also think that if we do have them, they should use SHOULD/MAY
> language instead of MUST. Using SHOULD/MAY would give guidance to
> implementors on how they can maximize interoperability while still allowing
> them total freedom (the implementation would still be conforming to the spec
> even if it went against a SHOULD/MAY guidance).

I agree with that too. EBMLMaxSizeLength was mentioned in the thread
and it would make sense to make a recursion limit per file in the EBML
header. That would let parsers know if they can handle the file or not
in advance and/or detect security attacks.

We could either have a default value for that element or none which
means there's no de-facto maximum.

It also not be an element but something more complex, since the amount
of recursion allowed may differ between elements (see nested tags vs
nested chapters). But it may be easier for the reader and the writer
to have only one limit for all.

In any case a default maximum valu would belong in the Matroska
specifications, not the EBML ones.

>> We don't talk anymore about security, and confidence depends on the
>> underlying document e.g. for my EBML document x, I may need only 1 level
>> beside the EBML header and it is fine with that, no need of more.
>> So:
>> - A minimum should not be in Security section (it is not about security)
>
>
> I agree that minimum or even maximum limits should not be placed in the
> security section. They belong elsewhere in the Matroska specification
> (exactly which section, I don't know). Sorry for not stating this more
> clearly in my original email.

We all agree.

>> - A minimum depends on the goal of the parser, e.g. a parser just checking
>> top level element size and CRC for checking a file transfer is fine does not
>> need more than 2 levels. Not all tools are video players.
>
>
> I'm not advocating for HOW the parsers should handle deep recursion (I
> probably shouldn't have used the language "abort the parse" in my original
> email; it was just meant to be a starting point for the conversation).
> Handling it by skipping it is fine. If a particular element is not needed
> for the goals of the application, the parser should certainly feel at
> liberty to skip over it.
>
>> But a player may just ignore any chapter and tag elements and still play
>> fine the file.

Not if the ordered chapters are truncated by enforcing a bogus maximum.

> Yes, the encoded media data can still be parsed/decoded and the media can
> still be played. But part of playing a video is showing to the user the
> chapter and tag information to the video. If the player ignores the chapter
> or tag elements, then the playback experience is incomplete. Not all players
> utilize the chapter and tag elements, but those that do will likely have
> some kind of upper limit on the level of recursion they can meaningfully
> handle.
>
> _______________________________________________
> Cellar mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar
>



-- 
Steve Lhomme
Matroska association Chairman