Fixes: loop.m3u
The default max iteration count of 1000 is arbitrary and ideas for a better solution are welcome
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Previous version reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7ec414892ddcad88313848494b6fc5f437c9ca4a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reduces the attack surface of local file-system
information leaking.
It prevents the existing exploit leading to an information leak. As
well as similar hypothetical attacks.
Leaks of information from files and symlinks ending in common multimedia extensions
are still possible. But files with sensitive information like private keys and passwords
generally do not use common multimedia filename extensions.
It does not stop leaks via remote addresses in the LAN.
The existing exploit depends on a specific decoder as well.
It does appear though that the exploit should be possible with any decoder.
The problem is that as long as sensitive information gets into the decoder,
the output of the decoder becomes sensitive as well.
The only obvious solution is to prevent access to sensitive information. Or to
disable hls or possibly some of its feature. More complex solutions like
checking the path to limit access to only subdirectories of the hls path may
work as an alternative. But such solutions are fragile and tricky to implement
portably and would not stop every possible attack nor would they work with all
valid hls files.
Developers have expressed their dislike / objected to disabling hls by default as well
as disabling hls with local files. There also where objections against restricting
remote url file extensions. This here is a less robust but also lower
inconvenience solution.
It can be applied stand alone or together with other solutions.
limiting the check to local files was suggested by nevcairiel
This recommits the security fix without the author name joke which was
originally requested by Nicolas.
Found-by: Emil Lerner and Pavel Cheremushkin
Reported-by: Thierry Foucu <tfoucu@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 189ff4219644532bdfa7bab28dfedaee4d6d4021)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes a null pointer dereference at least
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit cfda1bea4c18ec1edbc11ecc465f788b02851488)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
No case is known where these are needed
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6ba42b6482c725a59eb468391544dc0c75b8c6f0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7145e80b4f78cff5ed5fee04d4c4d53daaa0e077)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Context cookies must be updated when a playlist response return Setcookie header.
See: 770dd105044d00263da041f509a08b316296a78e
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without EXT-X-MAP support we miss the first bytes of some streams.
These streams worked by luck before byte-ranged segment support was added in
da7759b3579de3e98deb1ac58e642b861280ba54
Fixes ticket #4797.
(cherry picked from commit 909907948846dedf57a730a4d115d04d1117f9e5)
Conflicts:
libavformat/hls.c
Commit ad701326b43078b90 ("avformat/hls: open playlists immediately when
AVDISCARD_ALL is dropped") inadvertently caused first_packet to never be
cleared, causing select_cur_seq_no() to not use the specific code for
live streams.
In practice this means that when the user selects a different audio
track during live stream (i.e. non-VOD) playback, there may be some
additional delay as the code might select an incorrect segment at first,
and we have to wait for video to catch audio (if too late segment was
selected) or to download more following audio segments (if too early
segment was selected).
Fix that by restoring the zeroing of first_packet.
(cherry picked from commit fd74d45d5158812675105a3b4aeb29c67b82f7e8)
If there is no #EXT-X-BYTERANGE specified, there is no need to seek.
Seeking fails anyway for rtmp, because this protocol does not support
url_seek.
This fixes CNN.m3u from trac ticket 4797 (i.e. Debian bug #798189).
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
(cherry picked from commit f9f0b4c08e7dc2c178ede137af4f64ca84ab2deb)
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Broken by commit ba12ba859aabfa7153ba397d869db13acdaba340. This only
happens with HLS streams which use encryption and require preserving
cookies sent by the server.
Fixes trac issue #4846.
(cherry picked from commit 26eb2940079d0ec433cf9b2deae24560707cbcf8)
Comment was previously slightly incorrect.
Also, it was placed in the wrong location.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '0c73a5a53cc97f4291bbe9e1e68226edf6161744':
hls: Save and forward avio options
Conflicts:
libavformat/hls.c
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Apparently, some live streams can delete segments too early, maybe
because the client is too far behind. In this case, it's better to skip
the segment, instead of returning EOF. (Yes, the HLS demuxer actually
returns AVERROR_EOF if opening the segment returns a 404 HTTP error.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
SAMPLE-AES encryption is not commonly used yet, but without this patch
ffmpeg is thinking that the hls segments are not encrypted which
produces broken files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Not allocating the pls->ctx will crash in libavformat/hls.c:1410, where
it tries to dereference the field.
Sample: http://ec24.rtp.pt/liverepeater/rtpn.smil/playlist.m3u8
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The ones left using av_gettime are NTP timestamps (for RTCP,
which is specified to send the actual current realtime clock
in RTCP SR packets), and the NUT muxer timestamper, which is
documented as using wallclock time.
Signed-off-by: Martin Storsjö <martin@martin.st>
ffurl_seek() will not work even when it should be a no-op, so do not
call it on crypto protocol.
Also replace use of ffurl_size() for the same reason.
Reported-by: Michael Schenk <Michael.Schenk@albistechnologies.com>
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Since we are basically seeking the AVIOContext under the subdemuxer, we
need to flush the subdemuxer to avoid old packets from being read from
the packet queue after the seek.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Properly take stream_index into account so that a keyframe will be
looked for in the specified stream_index only.
Similarly, only check timestamp validity against the specified
stream_index.
Also remove code for stream_index == -1 case which does not actually
happen as it is handled by generic code.
This is based on an initial patch by James Deng.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Do not try to delay opening newly required playlists until a segment
switch. Applications expect that newly selected undiscarded streams are
available immediately, especially with alternative rendition streams
(selectable audio/subtitle tracks).
One might think that delaying variant stream switch until a segment
switch would allow a "seamless" switch without us having to download a
specific segment from two different variant playlists. However, that is
not the case, since the application would have to keep the previous
stream available (undiscarded) until the first packet of the newly
selected stream arrives, but by that time the demuxer would have already
downloaded the next segment of both variants.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
As per spec 3.4.3 ("A client MUST NOT assume that segments with the same
sequence number in different Media Playlists contain matching content.")
we cannot use sequence numbers for packet ordering.
This can be seen e.g. in the subtitle streams of
bipbop_16x9_variant.m3u8 that have considerably longer segments and
therefore different numbering.
Since the code now exclusively syncs using timestamps that may wrap, add
some additional checking for that.
According to the HLS spec all the timestamps should be in 33-bit MPEG
format and synced together.
v2: cleaner wrap detection
v3: further wrap detection improvements
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
While selecting a packet to return to caller in read_packet(), the code
corrects the timestamps for starting timestamps.
However, this is wrong, since for live streams the initial timestamps
might differ just because of the time delay between the retrieval of the
various Media Playlists.
Fortunately, spec 6.2.4 mandates that all variant streams must have
matching timestamps, so we do not need to correct for initial
timestamps.
Drop the correction code.
Note that ID3 timestamps were previously ignored, so this code was
previously actually needed.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Check if the playlist is still needed just before requesting the next
segment instead of after exhausting the previous segment.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Improve selection of the segment sequence number when restarting the
reception of a playlist after it was suspended due to being unneeded
(due to discard flags).
The current code assumes that each playlist contains matching data with
the same sequence number, while spec 3.4.3 specifically says that that
is not the case. Often subtitle playlists also have longer target
durations as well, causing the selection to be completely wrong.
Instead prefer using the playlist segment duration information for
non-live playlists, and other means if that is not possible.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Seeking needs to be tracked on a per-playlist basis, since the resyncing
code in hls_read_packet() has to sync each playlist to the seek
timestamp instead of stopping after the first playlist has reached it.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
HLS provides MPEG TS timestamps via ID3 tags in the beginning of each
segment of elementary audio streams.
v2: fix issues with streams that have multiple ID3 tags
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Add support for EXT-X-BYTERANGE added in HLS protocol v4.
v2: Better comment explaining ffurl_seek call and fix cur_seg_offset not
being updated.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Even if we returned AVERROR_EOF previously due to playlist no longer
being needed, we may still be called again, and we do not want to
trigger a segment download in that case.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
HLS protocol version 4 added alternative renditions to the
specification (e.g. alternative audio tracks).
The EXT-X-MEDIA tags can also contain metadata for "renditions" (i.e.
tracks) of the main Media Playlist.
Add support for those.
Note that the same rendition (AVStream) may be associated with multiple
variants (AVPrograms).
Alternative subtitle tracks will require additional work and are
therefore not enabled yet.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Session data (cookies, user-agent) is not being sent on payload requests with
encrypted HLS streams This causes services like Akamai to give a 403 forbidden
when requesting the TS files, because they expect the same cookies
and user-agent on all requests
