[FFmpeg-cvslog] rtmpproto: Support alternative slist parameter in rtmp URLs

[Reimar Döffinger]

On 07.05.2014, at 00:48, git at videolan.org (Uwe L. Korn) wrote:

> ffmpeg | branch: master | Uwe L. Korn <uwelk at xhochy.com> | Mon May  5 21:47:05 2014 +0100| [7ce3bd9614717e545af8fb8455032c807e389b78] | committer: Martin Storsjö
> 
> rtmpproto: Support alternative slist parameter in rtmp URLs
> 
> Support the URL scheme where the playpath is in an RTMP URL is
> passed as the slist argument and the app is given infront of the
> query part of the URL:
> 
> rtmp://host[:port]/[app]?slist=[playpath]
> 
> (other arguments in the query part are stripped as they are not used)
> 
> Signed-off-by: Martin Storsjö <martin at martin.st>
> 
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7ce3bd9614717e545af8fb8455032c807e389b78
> ---
> 
> libavformat/rtmpproto.c |   16 ++++++++++++++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
> index 8d8aabc..2962737 100644
> --- a/libavformat/rtmpproto.c
> +++ b/libavformat/rtmpproto.c
> @@ -2382,7 +2382,7 @@ static int rtmp_open(URLContext *s, const char *uri, int flags)
> {
>     RTMPContext *rt = s->priv_data;
>     char proto[8], hostname[256], path[1024], auth[100], *fname;
> -    char *old_app;
> +    char *old_app, *qmark, fname_buffer[1024];
>     uint8_t buf[2048];
>     int port;
>     AVDictionary *opts = NULL;
> @@ -2480,7 +2480,19 @@ reconnect:
>     }
> 
>     //extract "app" part from path
> -    if (!strncmp(path, "/ondemand/", 10)) {
> +    qmark = strchr(path, '?');
> +    if (qmark && strstr(qmark, "slist=")) {
> +        char* amp;
> +        // After slist we have the playpath, before the params, the app
> +        av_strlcpy(rt->app, path + 1, qmark - path);
> +        fname = strstr(path, "slist=") + 6;
> +        // Strip any further query parameters from fname
> +        amp = strchr(fname, '&');
> +        if (amp) {
> +            av_strlcpy(fname_buffer, fname, amp - fname + 1);

I would feel a lot more comfortable if those two strlcpy used FFMIN(..., sizeof(destination buffer)) instead.
At least not obvious how they are limited correctly, and I doubt there is not a major risk of future changes opening a trivially (direct stack buffer overflow) exploitable hole here.