[FFmpeg-devel] [PATCH 1/2] avformat/hls: Print input format in error message

[FFmpeg-devel] [PATCH 1/2] avformat/hls: Print input format in error message

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/hls.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index 93f6d1f1021..d2787ade46b 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -758,7 +758,7 @@ static int test_segment(AVFormatContext *s, const AVInputFormat *in_fmt, struct
             matchF = 3;
 
         if (!(matchA & matchF)) {
-            av_log(s, AV_LOG_ERROR, "detected format extension %s mismatches allowed extensions in url %s\n", in_fmt->extensions ? in_fmt->extensions : "none", seg->url);
+            av_log(s, AV_LOG_ERROR, "detected format %s extension %s mismatches allowed extensions in url %s\n", in_fmt->name, in_fmt->extensions ? in_fmt->extensions : "none", seg->url);
             return AVERROR_INVALIDDATA;
         }
     }
-- 
2.48.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Michael Niedermayer]

Maybe fixes: 11435

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
---
 libavformat/hls.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/libavformat/hls.c b/libavformat/hls.c
index d2787ade46b..bdc3f5dbed5 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -754,6 +754,10 @@ static int test_segment(AVFormatContext *s, const AVInputFormat *in_fmt, struct
         if (in_fmt->extensions) {
             matchF =      av_match_ext(    seg->url, in_fmt->extensions)
                      + 2*(ff_match_url_ext(seg->url, in_fmt->extensions) > 0);
+            if(!strcmp(in_fmt->name, "mov,mp4,m4a,3gp,3g2,mj2")) {
+                matchF |=      av_match_ext(    seg->url, "ts")
+                          + 2*(ff_match_url_ext(seg->url, "ts") > 0);
+            }
         } else if (!strcmp(in_fmt->name, "mpegts"))
             matchF = 3;
 
-- 
2.48.1

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Jan Ekström]

On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Maybe fixes: 11435
>

Do I understand correctly that the root issue that's being attempted
to be fixed by the initial patch set is that unusual demuxers were
possible to have been probed and opened through the HLS meta demuxer?
In that case I would say that instead of trying to make very nebulous
and easily breakable extension based checking, maybe this demuxer
should just limit its default usable input formats?

To my knowledge the officially utilized container formats for HLS are
MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
that should be a generally mostly encompassing thing that does not
depend on what extensions are in use. Adding an AVOption to add
additional formats without code changes would then allow for some
outliers to be added by users.

Finally, the `-f` format definition option and whatever logic
underneath it is just splitting the name on comma and then matching.
There probably is a helper function for this in the code base. This
enables just matching against "mp4" or so. While I consider it
unlikely that even more formats are going to be added to that list of
the mov/mp4/etc demuxer, hard-coding the full name sounds like a
somewhat bad idea (unless you're utilizing the exact same macro for
both the definition in mov.c as well as in here, making sure that both
get updated in sync).

Best regards,
Jan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4090 bytes --]

Hi

On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekström wrote:
> On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > Maybe fixes: 11435
> >
> 
> Do I understand correctly that the root issue that's being attempted
> to be fixed by the initial patch set is that unusual demuxers were
> possible to have been probed and opened through the HLS meta demuxer?
> In that case I would say that instead of trying to make very nebulous
> and easily breakable extension based checking, maybe this demuxer
> should just limit its default usable input formats?
> 
> To my knowledge the officially utilized container formats for HLS are
> MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
> MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
> that should be a generally mostly encompassing thing that does not
> depend on what extensions are in use. Adding an AVOption to add
> additional formats without code changes would then allow for some
> outliers to be added by users.

there is extended M3U
https://en.wikipedia.org/wiki/M3U

that allows a wide range of things in it

our hls demuxer can read these, if we limit to mpeg-ts/mp4 we would remove
support for these.

having an AVOption that is needed for some files is bad because
then people turn it on and if that makes it insecure ...


> 
> Finally, the `-f` format definition option and whatever logic
> underneath it is just splitting the name on comma and then matching.
> There probably is a helper function for this in the code base. This
> enables just matching against "mp4" or so. While I consider it

yeah, you are correct thats ugly, ill fix that

<JEEB> michaelni: alternatively I feel like since we've had meta demuxers have these issues having demuxers utilized that just read text from input, maybe we should just have some general meta demuxer logic which allows or disallows specific formats. allowlist is simpler since even if someone adds a new one it will not automatically be allowed (thus not enabling possible new "holes"), but on the other hand if
<JEEB> we can notice such formats as new ones happen to get added then a blocklist based on a "not allowed in meta demuxers" or "may easily cause information exfiltration" per-format flag might also be quite possible

there are many things that can be done, iam not against this
the CVE IIRC explicitly suggested extension checks


<nevcairiel> dont we already have tons of whitelists for things, having a demuxer whitelist sounds a lot better then doing it on extension, which is meaningless in msot cases - as seen here, ts is just used for anything

we have tons of whitelists and i have suggested their use everywhere including
the commit messages

They have some problem though and that is they are unflexible if set to
a fixed value by hand
if you get a unknown generic input what whitelist do you use ?
you need to have the demuxer on it that that file needs but you dont know
which that is.

I dont like hls and i dont like how our hls demuxer is "shared" with more
generic EXTM3U code. I think these 2 should be seperate AVInputFormat
in the same hls.c
Where the true HLS should be more locked down like you describe by default

but still teh more generic code benefits from simple checks we can
throw at it.
Simply blacklisting tty "demuxers" feels like a risky fix though
because tty is used by an attacker because its simple not because its the only
way to exfiltrate data. If you just run a raw decoder or pcm decoder or
even something simple like a RLE decoder you can likely achieve the same
its just an extra layer of work

Iam not sure and iam not feeling confident on any hls fix. This is all
more incremental improvments. Even if you can only run a TS demuxer or
MOV demuxer over /etc/passwd, i would not feel safe

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What is money laundering? Its paying someone and not telling the government.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Kacper Michajlow]

On Tue, 28 Jan 2025 at 22:44, Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi
>
> On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekström wrote:
> > On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > Maybe fixes: 11435
> > >
> >
> > Do I understand correctly that the root issue that's being attempted
> > to be fixed by the initial patch set is that unusual demuxers were
> > possible to have been probed and opened through the HLS meta demuxer?
> > In that case I would say that instead of trying to make very nebulous
> > and easily breakable extension based checking, maybe this demuxer
> > should just limit its default usable input formats?
> >
> > To my knowledge the officially utilized container formats for HLS are
> > MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
> > MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
> > that should be a generally mostly encompassing thing that does not
> > depend on what extensions are in use. Adding an AVOption to add
> > additional formats without code changes would then allow for some
> > outliers to be added by users.
>
> there is extended M3U
> https://en.wikipedia.org/wiki/M3U
>
> that allows a wide range of things in it
>
> our hls demuxer can read these, if we limit to mpeg-ts/mp4 we would remove
> support for these.
>
> having an AVOption that is needed for some files is bad because
> then people turn it on and if that makes it insecure ...
>
>
> >
> > Finally, the `-f` format definition option and whatever logic
> > underneath it is just splitting the name on comma and then matching.
> > There probably is a helper function for this in the code base. This
> > enables just matching against "mp4" or so. While I consider it
>
> yeah, you are correct thats ugly, ill fix that
>
> <JEEB> michaelni: alternatively I feel like since we've had meta demuxers have these issues having demuxers utilized that just read text from input, maybe we should just have some general meta demuxer logic which allows or disallows specific formats. allowlist is simpler since even if someone adds a new one it will not automatically be allowed (thus not enabling possible new "holes"), but on the other hand if
> <JEEB> we can notice such formats as new ones happen to get added then a blocklist based on a "not allowed in meta demuxers" or "may easily cause information exfiltration" per-format flag might also be quite possible
>
> there are many things that can be done, iam not against this
> the CVE IIRC explicitly suggested extension checks
>
>
> <nevcairiel> dont we already have tons of whitelists for things, having a demuxer whitelist sounds a lot better then doing it on extension, which is meaningless in msot cases - as seen here, ts is just used for anything
>
> we have tons of whitelists and i have suggested their use everywhere including
> the commit messages
>
> They have some problem though and that is they are unflexible if set to
> a fixed value by hand
> if you get a unknown generic input what whitelist do you use ?
> you need to have the demuxer on it that that file needs but you dont know
> which that is.
>
> I dont like hls and i dont like how our hls demuxer is "shared" with more
> generic EXTM3U code. I think these 2 should be seperate AVInputFormat
> in the same hls.c
> Where the true HLS should be more locked down like you describe by default
>
> but still teh more generic code benefits from simple checks we can
> throw at it.
> Simply blacklisting tty "demuxers" feels like a risky fix though
> because tty is used by an attacker because its simple not because its the only
> way to exfiltrate data. If you just run a raw decoder or pcm decoder or
> even something simple like a RLE decoder you can likely achieve the same
> its just an extra layer of work
>
> Iam not sure and iam not feeling confident on any hls fix. This is all
> more incremental improvments. Even if you can only run a TS demuxer or
> MOV demuxer over /etc/passwd, i would not feel safe

Hi,

I think the main point here is that FFmpeg is being forced to
implement "layers" of security that, at best, provide a false sense of
assurance. You should never run a large media processing library, one
that relies on dozens of third-party dependencies, without proper
sandboxing and strict access controls for relevant files.

That said, I do see some merit in extension filtering as a way to
reduce the scope of what FFmpeg attempts to read. However, we must
ensure that it aligns with the HLS specification and the practices of
major media providers. In #11435, I provided another example
(Twitter/X) that is currently being filtered in HEAD (88a8ba5c). (and
I'm sure there are servers that feeds files without extension and only
mime type)

I believe changes like this create more friction for users than actual
security benefits. I get it. Someone needed to hit their KPI by
submitting CVEs, and they found a marginally applicable case of a
highly unrealistic attack scenario.

But FFmpeg should be cautious about adopting questionable security
measures, such as:

> DASH playlists should restrict URIs to data:// and file:// unless otherwise specified with protocol_whitelist.

I mean, cool, but isn't DASH a Dynamic Adaptive Streaming over HTTP?

In summary, I believe the ability of FFmpeg to open or parse certain
formats is highly dependent on the deployment environment. If you
provide a service that allows foreign playlists to be opened on your
server, it is your responsibility to restrict access appropriately,
whether through sandboxing, firewalls, or by disabling unnecessary
demuxers and features in your FFmpeg binaries to minimize the attack
surface. There's even a useful configuration option to disable
networking if that suits your needs. For example, I fully expect my
libavformat to open DASH streams using the HTTP protocol, and I don’t
consider that a CVE issue simply because it has that capability.

- Kacper
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2572 bytes --]

Hi Kacper

On Tue, Feb 04, 2025 at 12:45:14PM +0100, Kacper Michajlow wrote:
[...]
> security benefits. I get it. Someone needed to hit their KPI by
> submitting CVEs, and they found a marginally applicable case of a
> highly unrealistic attack scenario.

I think you mis judge the (un)realism of this attack

prior to the patches, i can give you a m3u8 file and it will store
any local file in the output video

This is not even just a matter of video streaming services,
With a bit of social engeneering you can likely get people to
do that.
"Hey i found this odd file that encodes to different gibberish
 on each machien, iam an artist, doing an art project, can you
 just quickly reencode this and send me the mkv it generates ?"

Who would think that above will effectively give the attacker full
access to your machiene. unless you run this in a sandbox that has
no access to sensitve files



> 
> But FFmpeg should be cautious about adopting questionable security
> measures, such as:
> 
> > DASH playlists should restrict URIs to data:// and file:// unless otherwise specified with protocol_whitelist.
> 
> I mean, cool, but isn't DASH a Dynamic Adaptive Streaming over HTTP?
> 
> In summary, I believe the ability of FFmpeg to open or parse certain
> formats is highly dependent on the deployment environment. If you
> provide a service that allows foreign playlists to be opened on your
> server, it is your responsibility to restrict access appropriately,
> whether through sandboxing, firewalls, or by disabling unnecessary
> demuxers and features in your FFmpeg binaries to minimize the attack
> surface. There's even a useful configuration option to disable
> networking if that suits your needs. For example, I fully expect my
> libavformat to open DASH streams using the HTTP protocol, and I don’t
> consider that a CVE issue simply because it has that capability.

A local file by default should not open a network connection.
(otherwise one can count who, when and where a file is played)
The user can set the protocol_whitelist if she wants local files
to open network connections

if a m3u8 / dash / whatever file is remote on http then said file
is not local and can open other remote files but cannot open local
files by default
again the user can override that as she prefers

This is just a basic "same origin" policy

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2115 bytes --]

Hi

On Wed, Feb 05, 2025 at 07:41:39PM +0100, Michael Niedermayer wrote:
> Hi Kacper
> 
> On Tue, Feb 04, 2025 at 12:45:14PM +0100, Kacper Michajlow wrote:
> [...]
> > security benefits. I get it. Someone needed to hit their KPI by
> > submitting CVEs, and they found a marginally applicable case of a
> > highly unrealistic attack scenario.
> 
> I think you mis judge the (un)realism of this attack
> 
> prior to the patches, i can give you a m3u8 file and it will store
> any local file in the output video
> 
> This is not even just a matter of video streaming services,
> With a bit of social engeneering you can likely get people to
> do that.
> "Hey i found this odd file that encodes to different gibberish
>  on each machien, iam an artist, doing an art project, can you
>  just quickly reencode this and send me the mkv it generates ?"
> 
> Who would think that above will effectively give the attacker full
> access to your machiene. unless you run this in a sandbox that has
> no access to sensitve files

Ive tried to write an exploit for this and luckily it is not
that simple.

We can use data:// to feed both data and extension to force a demuxer
of our choice to be used

We can use crypto: to encrypt the extracted data so the user has no clue
what is extracted

And we dont need to have any probe succeed on the file we read.
The tty_extensions check also is not helping as it is not run on the target

I can read any file but only if it has a extension on the allowed_extensions
list or allowed_extensions is set to ALL.
This makes this luckily indeed difficult to exploit, i failed to find a
way to bypass this. But there are several close ones
concatdec uses data:// if we open it that way
file:// is subject to teh allowed_extensions check
other things like references in other demuxers i have not tried

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Leo Izen]

On 1/28/25 4:44 PM, Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekström wrote:
>> On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
>> <michael@niedermayer.cc> wrote:
>>>
>>> Maybe fixes: 11435
>>>
>>
>> Do I understand correctly that the root issue that's being attempted
>> to be fixed by the initial patch set is that unusual demuxers were
>> possible to have been probed and opened through the HLS meta demuxer?
>> In that case I would say that instead of trying to make very nebulous
>> and easily breakable extension based checking, maybe this demuxer
>> should just limit its default usable input formats?
>>
>> To my knowledge the officially utilized container formats for HLS are
>> MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
>> MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
>> that should be a generally mostly encompassing thing that does not
>> depend on what extensions are in use. Adding an AVOption to add
>> additional formats without code changes would then allow for some
>> outliers to be added by users.
> 
> there is extended M3U
> https://en.wikipedia.org/wiki/M3U
> 
> that allows a wide range of things in it
> 
> our hls demuxer can read these, if we limit to mpeg-ts/mp4 we would remove
> support for these.
> 

 From reading this, it seems like we're using the same demuxer for both 
HLS streams (specified informationally in RFC 8216) as well as for 
generic m3u playlists, and changes to the HLS implementation for 
security reasons also change the M3U demuxer.

Why don't we just separate this into two different demuxers/protocols?

- Leo Izen (Traneptora)

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2188 bytes --]

Hi Traneptora

On Tue, Feb 04, 2025 at 06:35:07PM -0500, Leo Izen wrote:
> 
> 
> On 1/28/25 4:44 PM, Michael Niedermayer wrote:
> > Hi
> > 
> > On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekström wrote:
> > > On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
> > > <michael@niedermayer.cc> wrote:
> > > > 
> > > > Maybe fixes: 11435
> > > > 
> > > 
> > > Do I understand correctly that the root issue that's being attempted
> > > to be fixed by the initial patch set is that unusual demuxers were
> > > possible to have been probed and opened through the HLS meta demuxer?
> > > In that case I would say that instead of trying to make very nebulous
> > > and easily breakable extension based checking, maybe this demuxer
> > > should just limit its default usable input formats?
> > > 
> > > To my knowledge the officially utilized container formats for HLS are
> > > MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
> > > MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
> > > that should be a generally mostly encompassing thing that does not
> > > depend on what extensions are in use. Adding an AVOption to add
> > > additional formats without code changes would then allow for some
> > > outliers to be added by users.
> > 
> > there is extended M3U
> > https://en.wikipedia.org/wiki/M3U
> > 
> > that allows a wide range of things in it
> > 
> > our hls demuxer can read these, if we limit to mpeg-ts/mp4 we would remove
> > support for these.
> > 
> 
> From reading this, it seems like we're using the same demuxer for both HLS
> streams (specified informationally in RFC 8216) as well as for generic m3u
> playlists, and changes to the HLS implementation for security reasons also
> change the M3U demuxer.
> 

> Why don't we just separate this into two different demuxers/protocols?

yes, i was thinking the same, we should do this for git master

thx


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: .ts is always ok even if its a mov/mp4

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2055 bytes --]

Hi

On Tue, Jan 28, 2025 at 10:12:30PM +0200, Jan Ekström wrote:
> On Tue, Jan 28, 2025 at 4:24 PM Michael Niedermayer
> <michael@niedermayer.cc> wrote:
> >
> > Maybe fixes: 11435
> >
> 
> Do I understand correctly that the root issue that's being attempted
> to be fixed by the initial patch set is that unusual demuxers were
> possible to have been probed and opened through the HLS meta demuxer?
> In that case I would say that instead of trying to make very nebulous
> and easily breakable extension based checking, maybe this demuxer
> should just limit its default usable input formats?
> 

> To my knowledge the officially utilized container formats for HLS are
> MPEG-TS, MP4-likes (fragmented mp4) and raw audio formats such as AAC,
> MP3 or AC-3. One could check what hls.js or ExoPlayer support, and
> that should be a generally mostly encompassing thing that does not
> depend on what extensions are in use. Adding an AVOption to add
> additional formats without code changes would then allow for some
> outliers to be added by users.

our allowed_extensions list kind of does this already now
because with extension_picky (the default now)
the probed format must itself declare an extension thats on
allowed_extensions

so tty can not be used with hls unless one adds it to allowed_extensions
completely independant of what extension the files have

also any demuxers not listing any extensions can not be used with
extension_picky, excpt mpegts which is added as a special case

The idea of extension_picky is that everything has to match
its not just a check on the file extension of the file
(well at least thats the idea until the next security researcher
finds a way around it)

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".