[FFmpeg-devel] [PATCH 10/18] avformat/hls: add support for byte-ranged segments

[Michael Niedermayer]

On Wed, Jan 01, 2014 at 12:32:10AM +0200, Anssi Hannula wrote:
> 31.12.2013 10:20, Clément Bœsch kirjoitti:
> > On Tue, Dec 31, 2013 at 09:28:05AM +0200, Anssi Hannula wrote:
> >> 31.12.2013 08:30, Clément Bœsch kirjoitti:
> >>> On Tue, Dec 31, 2013 at 05:13:03AM +0200, Anssi Hannula wrote:
> >>>> 31.12.2013 05:05, Michael Niedermayer kirjoitti:
> >>>>> On Mon, Dec 30, 2013 at 01:14:24PM +0200, Anssi Hannula wrote:
> >>>>>> Add support for EXT-X-BYTERANGE added in HLS protocol v4.
> >>>>>>
> >>>>>> Signed-off-by: Anssi Hannula <anssi.hannula at iki.fi>
> >>>>>> ---
> >>>>>>  libavformat/hls.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
> >>>>>>  1 file changed, 61 insertions(+), 2 deletions(-)
> >>>>>>
> >>>> [...]
> >>>>>> @@ -635,8 +671,22 @@ static int open_input(HLSContext *c, struct playlist *pls)
> >>>>>>      else
> >>>>>>        ret = AVERROR(ENOSYS);
> >>>>>>  
> >>>>>> +    /* Seek to the requested position. If this was a HTTP request,
> >>>>>> +     * the offset should already be there. */
> >>>>>> +    if (ret == 0) {
> >>>>>> +        int seekret = ffurl_seek(pls->input, seg->url_offset, SEEK_SET);
> >>>>>> +        if (seekret < 0) {
> >>>>>> +            av_log(pls->parent, AV_LOG_ERROR, "Unable to seek to offset %"PRId64" of HLS segment '%s'\n", seg->url_offset, seg->url);
> >>>>>> +            ret = seekret;
> >>>>>> +            ffurl_close(pls->input);
> >>>>>> +            pls->input = NULL;
> >>>>>> +        }
> >>>>>> +    }
> >>>>>
> >>>>> maybe i misunderstand something but why do you need to seek if the
> >>>>> offset was already provided to the protocol ?
> >>>>
> >>>> Well, in case the protocol is not HTTP. Of course that is indeed a bit
> >>>> far-fetched as it is "HTTP Live Streaming" ;)
> >>>>
> >>>> This was useful for local testing without needing a HTTP server, though.
> >>>> I'm not too heavily against removing it, but it doesn't really hurt
> >>>> either so I kept it...
> >>>
> >>> Does that mean a remote server can make you play local files?
> >>
> >> Apparently yes, hls uses just ff_make_absolute_url() so the playlist can
> >> just contain "file://local/file.ts".
> >>
> > 
> > I can't think of a way to communicate back information, but typically this
> > means the remote server can make you open sensitive files client side. A
> > blind attack might allow to guess the existence of files. If a sensible
> > file is somehow probed as a random playlist supported by FFmpeg, some url
> > in it might be fetched leaking some information.
> > 
> > Of course this is just theory, but the point is, I'd better have this code
> > surrounded by #if DEBUG, or enabled through a disabled by default option,
> > such as -allow_local_file or something.
> 
> Right, it is not a normal use case so we could restrict it to http/https
> by default and add "allow_any_protocol" (any proto allowed) or
> "allow_local_file" (http(s): and file: protos). Both is overkill, not
> sure which one to add yet.
> 
> However, personally I'm much more concerned about doing
> $ someplayer random_file.mp4
> when random_file.mp4 is actually a HLS playlist file and FFmpeg starts
> making HTTP connections to URLs in the file, which I would not really
> expect...
> I'm not sure what we could do about that, though... Maybe only have
> .probe() succeed if filename extension is .m3u(8)?
> The HLS standard specifies, though, that either the playlist extension
> should be .m3u(8) and/_or_ HTTP Content-Type is one of several strings.
> So theoretically playlist files delivered by HTTP could have random names...
> 
> Or WDYT?

one could enforce that the playlist protocol matches the
playlist entries protocolls
like a local playlist can access files while a http playlist is
limited to http
stricter "same origin" checks like same server or domain could be
tried too, i dont know if these are possible with real world hls
though or if this would break some streams

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140101/33f835ac/attachment.asc>