Opened 12 years ago
Closed 12 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 , 12 years ago
Cc: | added |
---|---|
Version: | unspecified → 1.1.2 |
follow-up: 3 comment:2 by , 12 years ago
follow-up: 4 comment:3 by , 12 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.
comment:4 by , 12 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 , 12 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 , 12 years ago
Priority: | normal → important |
---|---|
Version: | 1.1.2 → git-master |
Sounds important.
comment:7 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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