Re: [Cellar] Security considerations: recursive elements

[Jerome Martinez <[e-mail]>]

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