Subject: [Cellar] EBML Security Considerations section

From: Dave Rice <[email-masked]>
Date: Sat, 13 Feb 2016 16:04:36 -0500

Here is a draft Security Considerations section for the EBML spec. The section is based off Moritz’s comment here https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-99937237 with some minor re-wording.

==========================================

## Security Considerations

EBML itself does not offer any kind of security. It has nothing to do with authentication, it dose not provide confidentiality, only marginally useful and effective data integrity options (CRC elements).

EBML does not provide any kind of authorization.

Even if the semantic layer offers and kind of encryption EBML itself leaks information, at the least the sematic layer used via the DocType element, but also certain information about the structure from the elements (you can derive the presence of EBML elements even with an unknown semantic layer with a heuristic approach; not without errors, of course, but with a certain degree of confidence).

Attacks on an EBML reader may include:
- Invalid Element IDs that are longer than the limit stated in the EBMLMaxIDLength Element of the EBML Header.
- Invalid Element IDs that not encoded in the shortest-possible way.
- Invalid Element Ids comprised of reserved values.
- Invalid Element Data Size values that are longer than the limit stated in the EBMLMaxSizeLength Element of the EBML Header.
- Invalid Element Data Size values (e.g. extending the length of the Element beyond the scope of the Parent Element; possibly triggering access-out-of-bounds issues).
- Very high lengths in order to force out-of-memory situations resulting in a denial of service, access-out-of-bounds issues etc.
- Missing Elements that are mandatory and have no declared default value.
- Usage of 0x00 octets in EBML Elements with a string type.
- Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. in order to trigger acces-out-of-bounds or buffer overflow issues).
- Usage of invalid data in EBML Elements with a date type.

==========================================

Of the points, I don’t quite understand a few..

Originally Moritz wrote:
> Usage of \0 characters in EbmlString elements
I changed it to
> - Usage of 0x00 octets in EBML Elements with a string type.
but the string elements are allowed to be terminated with one or many 0x00 octets. What is an example of a null terminated EBML string that is a security consideration.

Regarding:
> - Usage of invalid data in EBML Elements with a date type.

Any 0 or 8 octet date value is valid, right? Other lengths are already invalid for date elements, so is this necessary to include?

A PR of the draft Security Considerations section is here: https://github.com/Matroska-Org/ebml-specification/pull/54.

Dave Rice

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 14 Feb 2016 16:11:17 +0100

> Here is a draft Security Considerations section for the EBML spec. The section is based off Moritz’s comment here https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-99937237 w…

It could also be an invalid size, like 13 for floats.

> - Invalid Element IDs that not encoded in the shortest-possible way.

Missing *is*

> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: Dave Rice <[email-masked]>
Date: Sun, 14 Feb 2016 11:23:12 -0500

> On Feb 14, 2016, at 10:11 AM, Steve Lhomme <[email-masked]> wrote:
> 

Not sure I understand. The Element Data Size is only expressed in VINT and the Floats of EBML are only within Elements defined as float. For instance is Matroska;Duration is expressed as a float value of 13, it is invalid, but is this a security issue?

>> - Invalid Element IDs that not encoded in the shortest-possible way.

Fixed locally.

---

From: Steve Lhomme <[email-masked]>
Date: Sun, 14 Feb 2016 17:29:51 +0100

> Not sure I understand. The Element Data Size is only expressed in VINT and the Floats of EBML are only within Elements defined as float. For instance is Matroska;Duration is expressed as a float va…

My bad. That comment was for the Element Size, not the Element ID.

>>> - Invalid Element Data Size values (e.g. extending the length of the Element beyond the scope of the Parent Element; possibly triggering access-out-of-bounds issues).

As said above. For elements with only a set of bounds you may not
extend the size. For example one could write a float of size 1.

---

From: Dave Rice <[email-masked]>
Date: Wed, 24 Feb 2016 23:23:28 -0500

> On Feb 14, 2016, at 11:29 AM, Steve Lhomme <[email-masked]> wrote:
> 

Here is the latest draft of the Security Consideration section. Thanks for the many suggestions in the mailing list and the pull request at https://github.com/Matroska-Org/ebml-specification/pull/54.

=================================================
## Security Considerations

EBML itself does not offer any kind of security. It has nothing to do with authentication; it does not provide confidentiality and offers only marginally useful and effective data integrity options (CRC elements).

Even if the semantic layer offers any kind of encryption, EBML itself may leak information at either the semantic layer (as declared via the DocType element) or within the EBML structure (you can derive the presence of EBML elements even with an unknown semantic layer with a heuristic approach; not without errors, of course, but with a certain degree of confidence).

Attacks on an EBML reader may include:
- 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 IDs comprised of reserved values.
- Invalid Element Data Size values that aren't allowed for the Element type (e.g. a length of 1 byte for an `EbmlFloat` element)
- Invalid Element Data Size values (e.g. extending the length of the Element beyond the scope of the Parent Element; possibly triggering access-out-of-bounds issues).
- Very high lengths in order to force out-of-memory situations resulting in a denial of service, access-out-of-bounds issues etc.
- Missing Elements that are mandatory and have no declared default value.
- Usage of 0x00 octets in EBML Elements with a string type.
- Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. in order to trigger access-out-of-bounds or buffer overflow issues).
- Usage of invalid data in EBML Elements with a date type.

=================================================

Best Regards,
Dave Rice