Subject: Re: [Cellar] Genart last call review of draft-ietf-cellar-ebml-09

From: Ben Campbell <[email-masked]>
Date: Fri, 1 Mar 2019 16:22:08 -0600

> On Feb 26, 2019, at 1:56 PM, Steve Lhomme <[email-masked]> wrote:
> 
> 
> On 26/02/2019 19:04, Steve Lhomme wrote:
>> The third paragraph of the Security Considerations section (including the
>> bullets) appears to say its ok to treat the following invalid things as valid.
>> If that's the case, why are they invalid in the first place? I think for some
>> of them, perhaps text has drifted and they are no longer invalid, but just
>> to be avoided when it is reasonable to do so? For those that really are invalid,
>> some text should be added describing _why_ they are ok to accept.
> 
> The following are considered usable even if not strictly valid:
> 
> - Invalid "Element IDs" that are longer than the limit stated in the "EBMLMaxIDLength Element" of the "EBML Header".
> - Invalid "Element IDs" that are not encoded in the shortest-possible way.
> - Invalid "Element Data Size" values that are longer than the limit stated in the "EBMLMaxSizeLength Element" of the "EBML Header".
> 
> These are not really invalid, just that they don't match what the EBML header says. They might be perfectly usable despite that.

Why would one create an EBML document that way? Or is this about recovering corrupted documents?

Thanks,

Ben.

> 
> - Invalid "Element IDs" comprised of reserved values.
> 
> This is more problematic. But the reserved values mean they could be used one day, so you may not choke on them. Either way it's fine to be strict or not.
> 
> - Usage of "0x00" octets in "EBML Elements" with a string type.
> 
> If found at the end of the string this is a waste of space. It may also be shortened strings in the middle. This may be explained better.
> 
> All these seem to just allow a parser to be very strict or very forgivable. But it's all usable data.
> 
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

---

From: Steve Lhomme <[email-masked]>
Date: Tue, 5 Mar 2019 15:19:54 +0100

Hi,

> Why would one create an EBML document that way? Or is this about recovering corrupted documents?

It may not be intentional but a code that assumes it will write a 
short/simple file and ends up having to use larger elements and 
forgetting to update the header (or crashing before editing the header 
in the end).

Since it's in the security section it may also be intentional to create 
bogus file to crash parsers that are tuned to only use the minimum 
resources.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 5 Mar 2019 10:54:56 -0600

> On Mar 5, 2019, at 8:19 AM, Steve Lhomme <[email-masked]> wrote:
> 
> Hi,
> 
> It may not be intentional but a code that assumes it will write a short/simple file and ends up having to use larger elements and forgetting to update the header (or crashing before editing the header in the end).

Has that been a problem in the field?  We don’t normally write specification for handling bugs, unless we think the bugs are specifically likely to happen.

> 
> Since it's in the security section it may also be intentional to create bogus file to crash parsers that are tuned to only use the minimum resources.

That’s worth mentioning in the text.

While Postel’s law says we that an implementation should be liberal in what it accepts, it can be dangerous to make implementations make judgement calls about whether an otherwise invalid document can still be used. That seems especially dangerous in light of the potential for this as an attack.

Do existing implementations attempt this?

Thanks!

Ben.

---

From: Moritz Bunkus <[email-masked]>
Date: Tue, 05 Mar 2019 18:09:45 +0100

Hey,

> Do existing implementations attempt this?

Partially, yes. The implementations that I know of don't care about these
two:

>>>> - Invalid "Element IDs" that are longer than the limit stated in the
>>>>   "EBMLMaxIDLength Element" of the "EBML Header".

>>>> - Invalid "Element Data Size" values that are longer than the limit
>>>>   stated in the "EBMLMaxSizeLength Element" of the "EBML Header".

They simply read up to eight bytes for the Element Data Size and up to four
bytes for the Element ID, no matter what the corresponding header values
state as the maximum.

Kind regards,
mosu

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 10 Mar 2019 14:34:48 +0100

> That’s worth mentioning in the text.

We split the potential security issues in 3 categories: can be handled
(not totally invalid), data to discard, potential secutiry attacks.

-- 
Steve Lhomme
Matroska association Chairman