HLS upload corrupted hostname any.tld -> any0.ts

[Chad]

Summary of the bug:
How to reproduce:

% ffmpeg -f lavfi -i anullsrc  -f hls 'https://example.ffmpeg/'
ffmpeg version 5.1.6-0+deb12u1
built on x86_64 debian linux

[tcp @ 0x556264c65a80] Failed to resolve hostname example0.ts: Name or service not known
[hls @ 0x556264c21280] Failed to open file 'https://example0.ts'
av_interleaved_write_frame(): Input/output error
[hls @ 0x556264c21280] Opening 'https://example0.ts' for writing
[tcp @ 0x556264c5d000] Failed to resolve hostname example0.ts: Name or service not known
[hls @ 0x556264c21280] Failed to open file 'https://example0.ts'
av_interleaved_write_frame(): Input/output error
[hls @ 0x556264c21280] Opening 'https://example0.ts' for writing
[tcp @ 0x556264c40600] Failed to resolve hostname example0.ts: Name or service not known
[hls @ 0x556264c21280] Failed to open file 'https://example0.ts'
av_interleaved_write_frame(): Input/output error
[hls @ 0x556264c21280] Opening 'https://example0.ts' for writing
[tcp @ 0x556264c40280] Failed to resolve hostname example0.ts: Name or service not known
[hls @ 0x556264c21280] Failed to open file 'https://example0.ts'
[tcp @ 0x556264c5c480] Failed to resolve hostname example.ffmpeg: Name or service not known

There is currently no ts top-level domain name, but this is a security problem in that the resolver will iterate through search space for names you did not define. If there becomes a "ts" TLD, then the entirety of uploads can be hijacked by anyone registering names within it!

Put "127.42.0.42 baz0.ts" in your resolver, like /etc/hosts .

Then use ffmpeg to stream to any "baz.$TLD", like baz.com or baz.example, and see ffmpeg attempt to connect to 127.42.0.42!

$ sudo tcpdump host 127.42.0.42 -i any -n

11:08:24.781749 lo    In  IP 127.0.0.1.40936 > 127.42.0.42.443: Flags [S], seq 4198081759, win 65495, options [mss 65495,sackOK,TS val 2139554443 ecr 0,nop,wscale 7], length 0
11:08:24.781756 lo    In  IP 127.42.0.42.443 > 127.0.0.1.40936: Flags [R.], seq 0, ack 4198081760, win 0, length 0
11:08:24.782013 lo    In  IP 127.0.0.1.40946 > 127.42.0.42.443: Flags [S], seq 1337330299, win 65495, options [mss 65495,sackOK,TS val 2139554443 ecr 0,nop,wscale 7], length 0
11:08:24.782017 lo    In  IP 127.42.0.42.443 > 127.0.0.1.40946: Flags [R.], seq 0, ack 1337330300, win 0, length 0
11:08:24.782219 lo    In  IP 127.0.0.1.40958 > 127.42.0.42.443: Flags [S], seq 3107017613, win 65495, options [mss 65495,sackOK,TS val 2139554444 ecr 0,nop,wscale 7], length 0
11:08:24.782222 lo    In  IP 127.42.0.42.443 > 127.0.0.1.40958: Flags [R.], seq 0, ack 3107017614, win 0, length 0
11:08:24.782306 lo    In  IP 127.0.0.1.40966 > 127.42.0.42.443: Flags [S], seq 4226785382, win 65495, options [mss 65495,sackOK,TS val 2139554444 ecr 0,nop,wscale 7], length 0
11:08:24.782309 lo    In  IP 127.42.0.42.443 > 127.0.0.1.40966: Flags [R.], seq 0, ack 4226785383, win 0, length 0

If you have corporate dns and have "company.com internal.company.com" in your DNS resolver search list and you try to upload to youtube.com, you will first try

youtube0.ts.

youtube0.ts.company.com.

youtube0.ts.internal.company.com.

and if any of those exist, then someone has hijacked your connection to youtube.com. .

[Chad]

The problem is probably around line 3067 of libavformat/hlsenc.c

in hls_init(), line 2948, set pattern to "%d.ts"

            pattern = hls->segment_type == SEGMENT_TYPE_FMP4 ? "%d.m4s" : "%d.ts";

and later on 3067,

            vs->basename = av_asprintf("%s%s", vs->m3u8_name, pattern);

so basename contains an unformatted "%d.ts". Basename sounds like something that could be truncated from some larger name.