Re: [Cellar] Security considerations: recursive elements

[Michael Bradshaw <[e-mail]>]

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.

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 <[e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cellar
>
>