diff options
author | wm4 <wm4@nowhere> | 2019-01-04 13:48:27 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2019-09-19 20:37:04 +0200 |
commit | d2ef2f98a861217d1374da9ae039c5cecdbb0e19 (patch) | |
tree | b865d56ec05fe493fa379c836cbc57f56a91429d /player/loadfile.c | |
parent | 7fad173cfda06724a0af33091c26eec937d0c6cf (diff) | |
download | mpv-d2ef2f98a861217d1374da9ae039c5cecdbb0e19.tar.bz2 mpv-d2ef2f98a861217d1374da9ae039c5cecdbb0e19.tar.xz |
loadfile, ytdl_hook: don't reject EDL-resolved URLs through playlist
The ytdl wrapper can resolve web links to playlists. This playlist is
passed as big memory:// blob, and will contain further quite normal web
links. When playback of one of these playlist entries starts, ytdl is
called again and will resolve the web link to a media URL again.
This didn't work if playlist entries resolved to EDL URLs. Playback was
rejected with a "potentially unsafe URL from playlist" error. This was
completely weird and unexpected: using the playlist entry directly on
the command line worked fine, and there isn't a reason why it should be
different for a playlist entry (both are resolved by the ytdl wrapper
anyway). Also, if the only EDL URL was added via audio-add or sub-add,
the URL was accessed successfully.
The reason this happened is because the playlist entries were marked as
STREAM_SAFE_ONLY, and edl:// is not marked as "safe". Playlist entries
passed via command line directly are not marked, so resolving them to
EDL worked.
Fix this by making the ytdl hook set load-unsafe-playlists while the
playlist is parsed. (After the playlist is parsed, and before the first
playlist entry is played, file-local options are reset again.) Further,
extend the load-unsafe-playlists option so that the playlist entries are
not marked while the playlist is loaded.
Since playlist entries are already verified, this should change nothing
about the actual security situation.
There are now 2 locations which check load_unsafe_playlists. The old one
is a bit redundant now. In theory, the playlist loading code might not
be the only code which sets these flags, so keeping the old code is
somewhat justified (and in any case it doesn't hurt to keep it).
In general, the security concept sucks (and always did). I can for
example not answer the question whether you can "break" this mechanism
with various combinations of archives, EDL files, playlists files,
compromised sites, and so on. You probably can, and I'm fully aware that
it's probably possible, so don't blame me.
Diffstat (limited to 'player/loadfile.c')
-rw-r--r-- | player/loadfile.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/player/loadfile.c b/player/loadfile.c index bb7365c641..fc3bb97a96 100644 --- a/player/loadfile.c +++ b/player/loadfile.c @@ -1429,7 +1429,7 @@ static void play_current_file(struct MPContext *mpctx) if (mpctx->demuxer->playlist) { struct playlist *pl = mpctx->demuxer->playlist; int entry_stream_flags = 0; - if (!pl->disable_safety) { + if (!pl->disable_safety && !mpctx->opts->load_unsafe_playlists) { entry_stream_flags = STREAM_SAFE_ONLY; if (mpctx->demuxer->is_network) entry_stream_flags |= STREAM_NETWORK_ONLY; |