Re: [Cellar] Roman Danyliw's Discuss on draft-ietf-cellar-flac-12: (with DISCUSS and COMMENT)

[Martijn van Beurden <[e-mail]>]

Hi Roman,

Once again many thanks for your thorough review of
draft-ietf-cellar-flac-12. Sorry for not getting back to you sooner on
this, I wasn't able due to health issues.

I've found most issues straightforward to alleviate, but for a few I'm
not sure what to do, so I was hoping you could provide some guidance.

Op di 17 okt 2023 om 18:21 schreef Roman Danyliw via Datatracker
<[e-mail]>:
>
> -- per value = 17, “A bright colored fish”, what is that?
>

This is something rather embarrassing really: this part of the
specification was directly copied from ID3v2 (which is most famously
used for tagging MP3 files), presumably to make implementing it as
easy as possible for applications that already implemented ID3v2.
However, I have no clue what this rather odd entry is about. I presume
it is a joke, but many people have wondered what it is too, and "the
internet" does not seem to have an answer. Some seem to think it is a
red herring, i.e., distracting from the (potentially flawed) stuff
that really matters.

What should I do? Should I remark that this is 'probably a joke'? Or
should I simply state this was included in ID3v2 for unknown reasons
and was copied to maintain compatibility?

> ** Section 8.8.  The URI mechanism described in the Picture field of the
> metadata block needs further security considerations.  The SECDIR review also
> pointed this out and discussion on possible new language has started.  This
> guidance needs to explicitly say that:
>
> -- the Security Considerations of RFC3986 apply (to cover threats of
> maliciously craft URLs)
>
> -- following external URLs introduces a tracking risk from on-path observers
> and the operator of the service hosting the URL.  Likewise, the choice of
> scheme, if it isn’t protected like https, could also introduce integrity
> attacks by an on-path observer.
>
> -- a malicious operator of the service hosting the URL can return arbitrary
> content that the parser will read
>
> -- implementers must guard against directory traversal attacks (since relative
> URIs are permitted) and be cognizant of same-origin issues (and localhost and
> local network) even more broadly
>
> -- (per SECDIR review) there could be a DoS attack against the operator of the
> service when the URI from the FLAC file is retrieved
>

I'm not sure what I could write about same-origin issues and directory
traversal attacks. Currently the spec says that for local files
referring to a local resource, the application MUST obtain user
approval to retrieve a resource not in the same directory. That should
make any possible attack dependent on user cooperation. Would further
limiting this, saying instead of obtaining user approval an
application MUST NOT retrieve a resource not in the same directory, be
warranted here? If not, I'm not sure how to restrict a directory
traversal attack on a local filesystem. Also, enforcing a same-origin
policy would make the point on DoS attacks moot, because then an
attacker could only use a file to attack the same server the file is
served from, so I'm unsure what same-origin issues apply here.

> ** Section 12
>    FLAC files may contain executable code, although the FLAC format is
>    not designed for it and it is uncommon.  One use case where FLAC is
>    occasionally used to store executable code is when compressing images
>    of mixed mode CDs, which contain both audio and non-audio data, of
>    which the non-audio portion can contain executable code.
>
> Thanks for calling this out.  From this cautionary text, it is not clear to me
> where in the FLAC format this executable code would be insert.  What guidance
> can be given to implementers about recognizing this executable code and
> treating it with care?
>

For the use case the document describes, a complete mixed-mode CD disc
image (binary + audio) is stored as if it were audio. As far as I
know, there isn't really a straightforward way to detect this, but
packing/unpacking of such files is often done fully at the users
discretion or with specialized tools aware of the context (i.e.,
programs working with disc images). I could add something on that FLAC
compression could be used to obscure or obfuscate executable code from
a malware scanner when stored as if it were audio, but I'm not sure
what to write on recognizing such code. See for example
https://en.wikipedia.org/wiki/BASICODE which is a system where
computer programs would be transferred via radio broadcasts and
listeners could record the program onto an audio cassette. I wouldn't
know how to write guidance on such cases. Can you perhaps point to an
RFC that deals with a similar issue?

Besides storage as audio executable code can be stored directly or
encoded as text, like pretty much every other file format. One could
store base64 encoded executable code as a vorbis comment field, but
this is also possible with any text file or email. One could also
store it directly with an application metadata block. One could also
hide it in a padding metadata block (which is supposed to be empty) or
in any other undefined or oversized metadata block. It seems to me
this is a problem with any file format, so I'm not sure what to write
here specifically. So, could you provide some guidance on where to
draw a line?

Many thanks in advance for helping me out.

Kind regards, Martijn van Beurden