Opened 5 years ago

Closed 5 years ago

#2292 closed defect (fixed)

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

Reported by: marcel123 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 Changed 5 years ago by marcel123

  • Cc msamek@gmail.com added
  • Version changed from unspecified to 1.1.2

comment:2 follow-up: Changed 5 years ago by 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

comment:3 in reply to: ↑ 2 ; follow-up: Changed 5 years ago by marcel123

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.

comment:4 in reply to: ↑ 3 Changed 5 years ago by cehoyos

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 Changed 5 years ago by marcel123

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 Changed 5 years ago by cehoyos

  • Priority changed from normal to important
  • Version changed from 1.1.2 to git-master

Sounds important.

comment:7 Changed 5 years ago by michael

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.