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

Clément Bœsch u at pkh.me
Tue Dec 31 09:20:37 CET 2013


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.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131231/d64f638d/attachment.asc>


More information about the ffmpeg-devel mailing list