Re: [Cellar] Security considerations: recursive elements

2018-01-17 23:47 GMT+01:00 Michael Bradshaw <mjbshaw@google.com>:
> Thanks for the responses, all!
>
> I agree that setting minimum/maximum recursion limits doesn't belong in the
> EBML spec. I do think the EBML spec should have a note in the Security
> Considerations that EBML Readers need to be cognizant of how they handle
> recursive elements and should be resilient to deeply nested recursion
> attacks (without giving particular recommendations for how that resilience
> is achieved). But EBML itself shouldn't attempt to set any specific limits
> on recursion depth.
>
> The reason I suggested setting some kind of minimum/maximum recursion depth
> (for Matroska specifically, not for EBML in general) is because of the
> points Michael Niedermayer raises. Setting a minimum allows muxers to write
> files with confidence that readers will be able to use/play the data being
> written (so long as the minimum isn't exceeded). Setting a maximum let's
> muxers know that if they exceed it, they run the risk of making a file that
> some readers can't (fully) play.

On the writer's side it's easier to know the maximum depth it reached
when writing a particular file and write the exact maximum value at
the end of the muxing. Security-wise it's stricter than a loose
default maximum.

> Specifying recursion limits using the example language in my first email ("a
> parser SHOULD handle recursion up to X levels deep, and MAY abort the parse
> if it reaches Y levels deep") for ChapterAtom and SimpleTag elements would
> allow a muxing program to emit a warning to the user if the recursion level
> exceeded Y (it's not a fatal error, but it would be nice to let the user
> know their file has abnormally deep recursion that might not be compatible
> with various parsers).
>
> On Wed, Jan 17, 2018 at 2:31 PM, Michael Niedermayer
> <michael@niedermayer.cc> wrote:
>>
>> 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.
>>
>> 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
>>
>> [...]
>>
>> --
>> 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
>>
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman