Ticket #1865 (closed defect: fixed)
sctp.c: abort() call can be hit by bad user input
|Reported by:||divVerent||Owned by:|
|Version:||git-master||Keywords:||crash abort sctp|
|Blocking:||Reproduced by developer:||yes|
|Analyzed by developer:||no|
Summary of the bug:
Because ffmpeg is a library, a mere bad URL passed to avio/ffurl code really shouldn't be able to cause a hard abort. However, exactly this is the case...
How to reproduce:
First set up a sctp listener:
% withsctp nc -vlp 127.0.0.1 1234
On another shell:
% catchsegv ./ffmpeg -f lavfi -i "life [out0]" -f nut "sctp://127.0.0.1:1234?max_streams=1" ffmpeg version N-46130-g67420b3 Copyright (c) 2000-2012 the FFmpeg developers built on Oct 29 2012 16:09:38 with gcc 4.7.2 (GCC) configuration: libavutil 52. 1.100 / 52. 1.100 libavcodec 54. 69.100 / 54. 69.100 libavformat 54. 35.100 / 54. 35.100 libavdevice 54. 3.100 / 54. 3.100 libavfilter 3. 20.106 / 3. 20.106 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 16.100 / 0. 16.100 [lavfi @ 0x23cf260] Estimating duration from bitrate, this may be inaccurate Input #0, lavfi, from 'life [out0]': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: rawvideo (B0W1 / 0x31573042), monob, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc Aborted
Why does it crash? Because the option max_streams in sctp.c causes packets to be required to start with the stream index in the first 16 bits of each packet to send. And e.g. the nut muxer does not ensure this.
The danger is that any generic code using avio and letting the URL come from user - or worse - untrusted sources (possibly after verifying protocol and host name) can crash this way.
This error condition probably should rather cause a log message with error return to packet sending, instead... or the max_streams option should rather be implemented in a way so it's not part of the URL, but rather a parameter the calling code has to set using a function.
- Keywords crash abort sctp added
- Status changed from new to open
- Reproduced by developer set