Re: [Cellar] Security considerations: recursive elements

2018-01-17 23:31 GMT+01:00 Michael Niedermayer <michael@niedermayer.cc>:
> On Wed, Jan 17, 2018 at 12:33:17PM -0800, Michael Bradshaw wrote:
>> The EBML and Matroska specs currently don't mention the possibility of a
>> stack overflow due to deeply nested recursive elements. Currently, there's
>> no limit on the recursion depth (unless I've overlooked it somewhere).
>>
>> I think it would be worth adding to the security section of EBML that one
>> type of attack on an EBML Reader could include deep element recursion.
>>
>
>> Additionally, I would like to see what people think about potentially
>> adding/suggesting an upper limit on recursion (either as a MUST or a MAY).
>> This could also include a lower limit too. 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".
>
> If a limit is specified then theres a limit that every compliant parser
> must support and which a compliant muxer can use.

IMO it should be per-file and not mandatory (ie no default max).

> If no such limit is specified then it is possible that in a system where
> all parts are specification compliant and otherwise compatible it doesnt work.
>
> So I think its more a question about what/when compatibility is guranteed
> / what compatibility we want the specification to gurantee
> from that it follows if we need a limit in the specification/draft or not

IMO it should be left to the parser to know what to do. The thing it
knows is that there's something wrong with the depth of the file and
may decide not to go deeper than the limit or issue a warning to the
user or ask if the extra parsing should be done.

All the specs have to say is that the maximum depth indicate the EBML
depth the file should not go further from. Emphasis on the SHOULD.

> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> If a bugfix only changes things apparently unrelated to the bug with no
> further explanation, that is a good sign that the bugfix is wrong.
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman