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

[Michael Richardson <[e-mail]>]

Martijn van Beurden <[e-mail]> wrote:
    > 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?

This.  "Copied to maintain integrity with historic sources"

    >> ** 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 seems like really enough advice.
Do we need to support relative URLs in the files?  Can we just say "MUST NOT"?

    > 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.

The same-origin restriction is good, but it does not cover all cases, and in
particular, it likely will get turned off if someone puts the file on a local
disk (file:// ) and then wants album covers from the network.

This is fundamentally implementation advice here in my opinion.
Implementers MUST ...

    >> 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).

FTP can also be used to transfer executable code :-)
The key is just ... not to execute it.
I don't understand why there is an extended issue here.
It's a container, it can contain stuff, and that stuff is sometimes not well identified.
Also, don't pull and Outlook and try to guess based content detection, rather
than using the Media-Type to determine things.

    > 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

Exactly.
I don't think there is much more to say other than "don't execute things"

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*