Subject: Re: [Cellar] Matroska Attachments

From: Dave Rice <[email-masked]>
Date: Sun, 20 Nov 2016 19:56:30 -0500

> On Mar 28, 2016, at 10:45 AM, Ben Campbell <[email-masked]> wrote:
> 
> On 28 Mar 2016, at 7:30, Steve Lhomme wrote:
> 
>> Having more ways to interact with attachments in Matroska seems like a
>>> good thing to me. Safely handling the attachments is up to the
>>> application anyway. Should anyone be concerned about security
>>> attachments could be ignored.
>> 
>> 
>> Yes, for example there might be a virus in a font and you might have
>> to install it on the system before you can use it. Same thing with a
>> PNG or a JPEG. That's already a concern with what we have now. But
>> it's out of the scope of Matroska how each type of file is used. As
>> long as we extract the proper data, not more, not less with the proper
>> strings attached, we're fine.
> 
> 
> Any ability to carry arbitrary (potentially executable) attachments will get scrutiny from at least the security ADs and the security directorate reviewer(s). I agree it's out of scope for Matroska to police those, but you will want to at least have language describing the issue, and to point out that applications (or OSs or something) need to police them.

I started adding this to the Security section:

Attacks on a `Matroska Reader` could include:
- Storage of a arbitrary and potentially executable data within an `Attachments Element`. `Matroska Readers` that extract or use data from Matroska Attachments SHOULD check that the data adheres to expectations.

Is there any particular boilerplate to include in a scenario like this?
Dave Rice

---

From: Dave Rice <[email-masked]>
Date: Sun, 20 Nov 2016 20:21:12 -0500

Hi all,

> On Mar 29, 2016, at 11:21 AM, Dave Rice <[email-masked]> wrote:
> 
>> On Mar 28, 2016, at 3:36 PM, Michael Niedermayer <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Mon, Mar 28, 2016 at 05:52:27PM +0200, Moritz Bunkus wrote:
>>> Hey,
>>> 
>>>> Presently an attached file in Matroska is only described with a
>>>> FileName, mimetype, and description. There is no permissions, uid,
>>>> gid, modification timestamps, etc. So IIUC there no method to clarify
>>>> if an attached file is executable or not.
>>>> 
>>>> Perhaps the specifications should clarify though, if any permissions
>>>> should be presumed of an attachment. For instance if a parser exports
>>>> the Attachment back to a file, what defaults should be used for
>>>> permissions and other file attributes.
>>> 
>>> I don't think that it's our (the spec's) job to specify how local system
>>> security should be managed. This would be a slippery slope. We're not
>>> security experts, and security is one of those fields someone has to be
>>> really knowledgeable to get it right.
>>> 
>>> I also don't see the point in making any kind of rules from our
>>> side. There are use cases across the whole board regarding system
>>> security: from not using any attachments at all; over keeping them in a
>>> temporary location only accessible to the current user and deleting them
>>> right after playback; to asking the user if she wants to install the
>>> fonts extracted from the attachments into the system's font database. It
>>> should not be up to the specs to make any kind of assumption here.
>>> 
>>> The specs should mention attachments and the various attack vectors in
>>> any future RFC's security section, of course.
>> 
>> The specs could list a "core" set of attachment mime types that
>> are recommanded to be supported.
> 
> +1
> 
>> That would make it easier for applications generating files to know
>> what can be put in that is likely going to be interpreted and
>> applications on the receiving end to know what minium set makes sense
>> to support. (or looking at it from the other side what mime types
>> can be ignored to minimize the attack surface without impacting the
>> majority of uses)
> 
> 
> For a whitelist we could use:
> text/*
> image/*
> video/*
> application/pdf
> application/xml
> others?
> 
> I've had trouble locating existing Matroska files with Attachments. The Internet Archive has ~90,000 matroska files and has been my largest sample set, but none of them use attachments. The primary examples of attachments I've seen come from samples.ffmpeg.org <http://samples.ffmpeg.org/>. Are there any other online collections of matroska files that may include attachments that I could analyze?
> Dave Rice

Using the recommendations of this thread I started working on attachments.md (which was previously named cover_art.md). I rewrote the cover art section in more formal language and added some security information. The latest work on this is in this pull request: https://github.com/Matroska-Org/matroska-specification/pull/73/files <https://github.com/Matroska-Org/matroska-specification/pull/73/files>.

I realize that although I often hear about Matroska's support for embedded fonts that I don't see much specification language anywhere about how to best handle font attachments. Are recommended practices for embedded fonts for subtitle use in scope of a Matroska specification? Anyone know of good existing documentation or practices for font handling in Matroska or volunteer to write some?

Best Regards,
Dave Rice