Re: [Cellar] Security considerations: recursive elements

2018-01-17 22:01 GMT+01:00 Jerome Martinez <jerome@mediaarea.net>:
> On 17/01/2018 21:33, Michael Bradshaw wrote:
>>
>> [...]
>>
>> For example, something like "a parser SHOULD handle recursion up to X
>> levels deep, and MAY abort the parse if it reaches Y levels deep".
>>
>> Thoughts from others?
>
>
> an EBML parser can not dig in nested element without the corresponding
> dictionary (from DocType).
> So IMO it is not like XML or JSON, because XML or JSON parser tries to read
> the nested elements, but n EBML parser does not try to read any element not
> in the dictionary (so the limit is the dictionary, usually can not be
> provided by the attacker.
> It is lie JSON or XML only if the attacker can provide the dictionary.
>
> And the JSON spec specifies no limit:
> https://tools.ietf.org/html/rfc7159#section-9
> "An implementation may set limits on the maximum depth of nesting"
>
> There may be legitimate reason to have thousands of nesting level, and there
> is already a lot of debates about that with JSON (last tests I saw about
> that is ~100 levels for Ruby JSON default parser and ~1000 levels for Python
> JSON parser)
>
> So the sentence should split security issues, from the input (the file
> itself) or the dictionary (e.g. matroska specs):
> - a generic parser (reading the dictionary from input) MAY set limits on the
> maximum depth of nesting. An implementation MAY set limits on the length and
> contents.

Yes, we need an element to specify that.

> - a specialized parser (e.g. Matroska parser) SHOULD handle recursion up to
> the maximum nesting level provided by the supported dictionary of the

Yes, and going further is left to implementation.

Parsers will need to handle the case where the element is not defined
too. So they can fallback to the rule in case the maximum is reached.

> document, or 2 nesting levels, whichever is smaller (a specialized format
> could have only 1 nesting level but EBML needs at least 2, for DocType
> etc...). An alternative is to say to rely on the supported format security
> paragraph.
>
> I am not in favor of writing a number, because there is no good number to
> provide, it depends too much of the content, I am in favor of doing like
> JSON sentences (without any number, but explicitly saying that limits are
> expected).
> I hesitate in writing such kind of text in a "parser" section instead of
> security section, like the JSON RFC does.
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman