• r00ty@kbin.life
      link
      fedilink
      arrow-up
      6
      ·
      13 hours ago

      From a cursory look at just the security commits. Looks like the following:

      • GHSA-j2hf-x4q5-47j3: Checks if a media shortcut is empty, and checks if it is remote and stores the remote protocol if so. Also prevent strm files (these are meant to contain links to a stream) from referencing local files. Indeed this might have been used to reference files jellyfin couldn’t usually see?
      • GHSA-8fw7-f233-ffr8: Seems to be similar, except for M3U file link validation and limiting allowed protocols. It also changes the default permissions for live TV management to false.
      • GHSA-v2jv-54xj-h76w: When creating a structure there should be a limit of 200 characters for a string which was not enforced.
      • GHSA-jh22-fw8w-2v9x: Not really completely sure here. They change regex to regexstr in a lot of places and it looks like some extra validation around choosing transcoding settings.

      I’m not really sure how serious any of these are, or how they could be exploited however. Well aside from the local file in stream files one.

      • chuso@fedia.io
        link
        fedilink
        arrow-up
        2
        ·
        12 hours ago

        Yeah, the key seems to be in the comments from one of the changes: https://github.com/jellyfin/jellyfin/commit/0581cd661021752e5063e338c718f211c8929310#diff-bcc2125e56d5738b4778802ac650ca47719845aeee582f3b5c9b46af82ea9979R1176-R1180

        It seems there was the potential risk that insufficient validation could allow reading arbitrary server files, which indeed poses a security risk.

        However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that’s a risk to ignore, but it’s not like it could be exploited by anyone on the Internet.

        • r00ty@kbin.life
          link
          fedilink
          arrow-up
          3
          ·
          9 hours ago

          However, my understanding is that this could be exploited only by authenticated users with permission to add new media. Not like that’s a risk to ignore, but it’s not like it could be exploited by anyone on the Internet.

          I wonder if that’s the reason for setting the default live TV management permission to false. Since that permission might well the the route to adding your own malicious m3u link for that second change.