Opened 11 years ago

Closed 11 years ago

#2292 closed defect (fixed)

Crash: Buffer overflow in rtmp_open() [libavformat/rtmpproto.c]

Reported by: Marcel Samek Owned by:
Priority: important Component: avformat
Version: git-master Keywords: RTMP
Cc: msamek@gmail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I have been working with RTMP streaming to YouTube. The URLs that YouTube generates when creating their "Live Events" are very long. I was getting a heap corruption which I tracked down to the following:

In rtmpproto.c

#define APP_MAX_LENGTH 128

YouTube generates URLs where the app portion of the URL is usually longer than 128 bytes. The code in rtmp_open() only allocates APP_MAX_LENGTH bytes and does not check for an overflow. As a result, the long YouTube RTMP URL is causing a heap corruption.

I verified that allocating the appropriate size buffer does fix the problem I was seeing.

Change History (7)

comment:1 by Marcel Samek, 11 years ago

Cc: msamek@gmail.com added
Version: unspecified1.1.2

comment:2 by Carl Eugen Hoyos, 11 years ago

Is the problem also reproducible with current git head?

Please provide the failing command line together with complete, uncut console output and for all crashes, please provide backtrace etc. as explained on http://ffmpeg.org/bugreports.html

in reply to:  2 ; comment:3 by Marcel Samek, 11 years ago

Replying to cehoyos:

Is the problem also reproducible with current git head?

Please provide the failing command line together with complete, uncut console output and for all crashes, please provide backtrace etc. as explained on http://ffmpeg.org/bugreports.html

Unfortunately I don't have the current git tree and don't have the time to grab it and try it. The code I was working with came from a zip file containing the official release.

We are working with the libraries in a custom application, so the command line and console output would not be useful to you.

I also don't have the backtrace anymore. It wasn't completely relevant because it wasn't crashing at the point where the heap was getting corrupted; it was crashing downstream on subsequent memory/heap operations.

Once we debugged the problem, we fixed it in our version of the tree and moved forward. Since we know exactly what the cause of the problem was we thought we would report it here. We are no longer blocked by this issue, so you may close the bug regport if you feel it is not useful.

in reply to:  3 comment:4 by Carl Eugen Hoyos, 11 years ago

Replying to marcel123:

Once we debugged the problem, we fixed it in our version of the tree

Then please provide the patch to allow avoiding duplicate work.

comment:5 by Marcel Samek, 11 years ago

I would be glad to contribute a patch if my fix was good enough. Unfortunately, I only increased the default buffer size to make sure that it met our specific needs. I did not take the time to write the code to check for a buffer overflow condition and fail gracefully if one occurs and that's what really needs to be done.

comment:6 by Carl Eugen Hoyos, 11 years ago

Priority: normalimportant
Version: 1.1.2git-master

Sounds important.

comment:7 by Michael Niedermayer, 11 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.